COUNT(*)和COUNT(列名)结果不相等是因为前者统计所有物理行（含NULL），后者仅统计该列非NULL值，差值即该列NULL数量，属SQL标准强制行为；常见于主键列未设NOT NULL约束或LEFT JOIN后右表字段为NULL场景。
为什么COUNT(*)和COUNT(列名)结果总是不相等
COUNT(*)统计的是结果集里的物理行数，不管任何列是否为NULL；COUNT(列名)只统计该列值不为NULL的行——差值就是该列NULL的数量，这是SQL标准强制行为，不是bug或配置问题。
常见现象：COUNT(id)返回98，COUNT(*)返回100 → 说明有2行的id列值为NULL（哪怕它是主键字段，只要没加NOT NULL约束，就可能存NULL）。
-
''（空字符串）、0、false都算非NULL，会被COUNT(列名)计入 - 只有真正的
NULL被跳过，'NULL'（字符串）照样计入 -
COUNT(*) - COUNT(列名)是最直接验证该列NULL数量的方式
COUNT(列名)在LEFT JOIN后为什么常“少得离谱”
LEFT JOIN会让右表字段在匹配失败时变成NULL，这时COUNT(右表.列名)实际统计的是“成功关联的行数”，而不是左表原始行数。
例如：SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id → 结果是连接后总行数，可能因一对多而膨胀；而COUNT(users.id)会把所有users.id IS NULL的行排除，结果可能远小于订单总数。
- 真正想统计“有多少订单”，应写
COUNT(DISTINCT orders.id)或改用子查询 - 别依赖
COUNT(*)在JOIN后的结果推断主表行数，它数的是连接产物，不是原始实体 -
COUNT(右表.列名)语义其实是“有多少行完成了有效关联”，不是“有多少左表记录”
COUNT(*)为什么通常比COUNT(列名)更快
COUNT(*)只需确认行存在性，优化器可走最小索引扫描甚至元数据估算；COUNT(列名)必须读取该列实际值并逐行判空，开销更高。
- 无
WHERE时，MySQL InnoDB 8.0+ 对COUNT(*)可能跳过读取行数据，只遍历索引页记录数 -
COUNT(列名)即使该列有索引，若允许NULL，优化器仍需确认每条索引项对应行是否真实存在（避免幻读），无法完全跳过回表 - 列无索引 + 允许
NULL→COUNT(列名)大概率触发全表扫描 -
COUNT(1)和COUNT(*)执行计划几乎一致，无需刻意替换
最容易被忽略的NULL处理时机
NULL判断发生在WHERE和GROUP BY之后——COUNT(列名)反映的是当前结果集里该列的非空数量，不是原始表分布。
一旦在复杂查询里混淆这点，指标偏差不会报错，只会静默出错。比如带WHERE status = 'active'后再COUNT(email)，统计的是“活跃用户中填了邮箱的人数”，而非“全部用户中填邮箱的人数”。
确认业务含义前，先跑一句：SELECT COUNT(*), COUNT(列名), COUNT(*) - COUNT(列名) FROM 表看NULL占比，比查表结构或猜逻辑更可靠。
