count(*)统计结果集所有物理行，count(列名)仅统计该列非null值，故后者恒≤前者；差值即该列null数量，是sql标准强制行为，非bug。
COUNT(*) 和 COUNT(列名) 结果不同，不是 bug，是 SQL 标准强制行为：前者数行，后者数非 NULL 值。
为什么 COUNT(列名) 总是 ≤ COUNT(*)
COUNT(*) 统计结果集中所有物理行，不管任何列是否为 NULL；COUNT(列名) 必须逐行读取该列值，并跳过所有 NULL。哪怕该列是主键、有索引、甚至业务上“理应不为空”，只要表定义允许 NULL（即没加 NOT NULL 约束），就可能存入 NULL —— INSERT 时漏传、ETL 清洗遗漏、LEFT JOIN 后右表字段失配，都会导致差值。
常见现象：COUNT(id) 返回 98，COUNT(*) 返回 100 → 说明有 2 行的 id 是 NULL。''（空字符串）、0、false 都算非 NULL，只有真正的 NULL 被跳过。
-
'NULL'（字符串字面量）不是NULL，会被计入 - 差值
COUNT(*) - COUNT(列名)就是该列真实的NULL数量，比查表结构或猜业务更可靠 - 即使字段定义为
DEFAULT 'N/A'，若没设NOT 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(*)在 JOIN 后数的是连接产物，不是原始实体；COUNT(右表.列名)语义其实是“有多少行完成了有效关联” - 别用
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'，统计的是“活跃用户中填了邮箱的人数”，不是“全部用户中填邮箱的人数”。这种偏差不会报错，只会静默出错，尤其在指标口径对齐和报表校验时极易被跳过。
真正要稳住语义，得盯住三件事：该列有没有 NOT NULL 约束、有没有针对查询条件建联合索引、以及你到底想统计“行存在性”还是“列有效性”——这两个目标从来就不是一回事。
