为什么SQL COUNT字段与COUNT星号结果不同

COUNT(字段)的值始终小于等于COUNT(*)，这是因为COUNT(字段)仅对该字段中的非NULL值进行统计，而COUNT(*)则会统计所有的物理行。两者的差值就是该字段中NULL值的数量，这是SQL标准规定的行为，并非程序错误。

为什么COUNT(字段)总是 ≤ COUNT(*)

COUNT(*)统计的是结果集的实际行数，无论任何列是否为NULL；而COUNT(字段)则会逐行检查该列的值——只要满足字段IS NULL，这一行就会被排除在外。它们的差值便是该列中NULL的数量，这是SQL标准所规定的行为，并非是程序错误。

• ''（空字符串）、0、false 全算非 NULL，会被 COUNT(字段) 计入；只有数据库层面真正的 NULL 被排除
• 常见现象：COUNT(id) 返回 98，COUNT(*) 返回 100 → 说明有 2 行的 id 是 NULL（哪怕它是主键字段，只要没加 NOT 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(字段) 的位置或函数选择

COUNT(*) 和 COUNT(字段) 的性能差异真实存在但常被高估

差别主要来自是否需要判空和索引利用路径，不是“哪个更快”的简单问题。

• COUNT(*) 在无 WHERE 时，MySQL InnoDB 8.0+ 可能走元数据估算或最小索引扫描，开销极小
• COUNT(字段) 必须读取该列实际值判断是否为 NULL；若该列无索引，大概率触发全表扫描
• 即使该列有索引，若允许 NULL，优化器仍需确认每条索引项对应行是否真实存在（避免幻读），无法完全跳过回表
• COUNT(1) 和 COUNT(*) 在现代数据库中执行计划几乎一致，别为了“看起来快”刻意替换

最容易被忽略的点：NULL 处理发生在 WHERE 和 GROUP BY 之后

COUNT(字段) 反映的是当前结果集里该字段的非空数量，不是原始表分布。一旦在复杂查询里混淆这点，指标偏差不会报错，只会静默出错。

• 例如带 WHERE status = 'active' 的查询中，COUNT(email) 统计的是“活跃用户中邮箱非空的数量”，不是全表邮箱填充率
• GROUP BY 后再用 COUNT(字段)，每一组内的计数都只基于该组内该字段的 NULL 分布
• LEFT JOIN + WHERE 右表字段条件（如 WHERE users.name IS NOT NULL）会把外连接转为内连接，此时 COUNT(users.name) 和 COUNT(*) 可能相等，但语义已彻底改变