count(*)统计所有物理行，count(列名)仅统计该列非null值；差值即该列真实null数量，是sql标准强制行为，非bug。
COUNT(*) 统计行数，COUNT(列名) 统计该列非 NULL 值数量——这是语义本质区别，不是性能或写法偏好问题。
为什么 COUNT(*) 和 COUNT(列名) 结果不一致
差值就是该列真实存在的 NULL 行数，不是数据错、不是 bug，是 SQL 标准强制行为。
-
COUNT(*)只看“有没有这一行”，哪怕所有列都是NULL，也计入 -
COUNT(列名)必须读取该列值，NULL被跳过；''、0、false都算非NULL，只有真正的NULL不计 -
'NULL'（带引号的字符串）不是NULL，会被COUNT(列名)计入 - 常见现象：
COUNT(id)返回 98，COUNT(*)返回 100 → 说明有 2 行id IS NULL，哪怕id是主键字段，只要没加NOT NULL约束，就可能存NULL
LEFT JOIN 后 COUNT(右表.列名) 为什么“少得离谱”
它统计的不是右表总行数，而是“左表中成功关联到右表的行数”。
-
SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id→ 返回连接后总行数（一对多会膨胀） -
COUNT(users.id)→ 实际等价于COUNT(CASE WHEN users.id IS NOT NULL THEN 1 END)，只统计users.id非NULL的行，即关联成功的订单数 - 想统计“有多少订单”，应写
COUNT(DISTINCT orders.id)或先子查询聚合，别用COUNT(users.id)去反推用户数 - 这个差值反映的是关联质量，不是数量偏差
COUNT(*) 为什么通常比 COUNT(列名) 更快
关键不在括号里填什么，而在是否需要读列值并判空。
-
COUNT(*)只需确认行存在性，优化器常走最小索引（如主键），甚至只扫索引页元数据 -
COUNT(列名)必须读取该列实际值并逐行判断是否为NULL；若该列允许NULL且无索引，大概率触发全表扫描 - 即使该列有索引，若
NULL占比高（比如 60%），二级索引遍历成本仍高于扫主键索引（更宽、页更多） -
COUNT(id)在id是NOT NULL主键时，优化器可能等价处理；但只要定义允许NULL，就不能跳过判空逻辑
最容易被忽略的 NULL 处理时机
COUNT(列名) 统计的是当前中间结果集里的非空数量，不是原始表分布。
- 例如：
SELECT COUNT(email) FROM users WHERE status = 'active'，统计的是“活跃用户中填了邮箱的人数”，不是“全部用户中填邮箱的人数” -
WHERE和GROUP BY先执行，COUNT(列名)再在过滤/分组后的结果上判空——这个顺序不可逆，也无法绕过 - 一旦在复杂查询中混淆这点，指标偏差不会报错，只会静默出错
- 真正要查某列 NULL 数量，最可靠方式就是
COUNT(*) - COUNT(列名)，比看表结构或猜业务更准
