COUNT(*)统计所有行（含NULL），COUNT(列名)仅统计该列非NULL值；二者差异源于SQL标准对NULL的强制忽略机制，非bug。
COUNT(列名) 和 COUNT(*) 统计结果经常不一致，根本原因在于 NULL 值是否被计入——这不是 bug，是 SQL 标准定义的行为。
为什么 COUNT(列名) 会比 COUNT(*) 少？
因为 COUNT(列名) 只统计该列值 非 NULL 的行；而 COUNT(*) 统计所有行，无论任何列是否为 NULL。
常见错误现象：COUNT(id) 返回 98，COUNT(*) 返回 100 → 说明有 2 行的 id 列值为 NULL（哪怕主键列也可能是 NULL，如果没设 NOT NULL 约束）。
- NULL 是缺失值，不是空字符串
''，也不是数字0，三者在COUNT(列名)中表现完全不同 -
COUNT(列名)对每一行先判断该列是否为 NULL，再决定是否累加 —— 这步判断带来微小但可测的开销 - 如果该列有索引（尤其是主键或唯一非空索引），某些数据库（如 MySQL InnoDB）可能复用索引元数据加速
COUNT(列名)，但依然要过滤 NULL
COUNT(*) 在 LEFT JOIN 场景下容易误用
当写 SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id，结果不是“订单数”，而是“连接后产生的总行数”——如果一个订单匹配多个用户（比如历史账号合并），就会重复计数。
这时若想真正统计“有多少订单”，必须明确语义：
- 要主表行数：改用
COUNT(DISTINCT orders.id)或子查询 - 要有效关联数：用
COUNT(users.id)，它自动跳过users.id为 NULL 的左连接失败行 - 别依赖
COUNT(*)推断业务逻辑，JOIN 后的“行”已不是原始表的行
性能差异真实存在，但通常不构成瓶颈
在大多数 OLTP 场景下，三者性能差距极小；但在大数据量或高频调用时，差异会暴露：
-
COUNT(*)：优化器通常走最小索引（如聚簇索引）或元数据估算（MySQL InnoDB 8.0+ 对无 WHERE 的COUNT(*)有快速路径） -
COUNT(列名)：若列无索引，引擎必须读取该列实际值判断 NULL；若列是主键且NOT NULL，部分优化器会等价于COUNT(*) -
COUNT(1)和COUNT(*)在主流数据库中执行计划几乎一致，无需刻意替换 —— 用COUNT(*)更符合语义直觉
最易被忽略的一点：NULL 处理逻辑是强制的、不可绕过的。即使你给列加了 DEFAULT 'N/A'，只要没加 NOT NULL 约束，INSERT 时显式写 NULL 仍会触发跳过统计。确认业务含义前，先查 SELECT COUNT(*), COUNT(列名), COUNT(*) - COUNT(列名) FROM 表 看 NULL 占比。
