COUNT(*)统计所有物理行，COUNT(列名)仅统计该列非NULL值，故后者恒≤前者；差值即该列NULL数量，是SQL标准强制行为，非bug。
COUNT(*) 和 COUNT(列名) 结果不同，不是 bug，是 SQL 标准强制行为：前者数行，后者数非 NULL 值。
为什么 COUNT(列名) 总是 ≤ COUNT(*)
COUNT(列名) 必须逐行读取该列值，并跳过所有 NULL；COUNT(*) 只确认行是否存在，不读任何列。哪怕该列是主键、有索引、业务上“理应不为空”，只要表定义允许 NULL（即没加 NOT NULL 约束），就可能存入 NULL。
-
INSERT时漏传字段 → 该列写入NULL - ETL 清洗遗漏或源数据含
NULL→ 直接入库 -
LEFT JOIN后右表无匹配 → 关联字段自动为NULL -
''（空字符串）、0、false都算非NULL，只有真正的NULL被跳过 -
'NULL'（字符串字面量）不是NULL，会被计入
LEFT JOIN 后 COUNT(右表.列名) 为什么“少得离谱”
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(users.id)校验用户总数——它反映的是关联质量，不是数量
COUNT(*) 为什么通常比 COUNT(列名) 更快
COUNT(*) 只需确认行存在性，优化器常走最小索引（如主键）扫描，甚至只读索引页元数据；COUNT(列名) 必须读取该列实际值并逐行判空，开销更高。
- 列无索引 + 允许
NULL→COUNT(列名)大概率触发全表扫描 - 列有索引但
NULL占比高（如 60%）→ 二级索引遍历成本仍高于扫主键索引（因更宽、页更多） -
COUNT(1)和COUNT(*)执行计划几乎一致，无需刻意替换 - 性能差异主要来自
NULL和索引，不是括号里填什么
最容易被忽略的 NULL 处理时机
NULL 判断发生在 WHERE 和 GROUP BY 之后——COUNT(列名) 统计的是当前中间结果集里该列的非空数量，不是原始表分布。
- 例如：
SELECT COUNT(email) FROM users WHERE status = 'active'，统计的是“活跃用户中填了邮箱的人数”，不是“全部用户中填邮箱的人数” - 差值
COUNT(*) - COUNT(列名)就是该列真实的NULL数量，比查表结构或猜业务更可靠 - 一旦在复杂查询里混淆这点，指标偏差不会报错，只会静默出错
