SQL中COUNT()与COUNT(列名)结果差异，NULL值如何影响聚合函数计数？

本文共计742个文字，预计阅读时间需要3分钟。

在SQL查询中，可以使用以下方式计算满足特定条件的记录数量：

为什么 COUNT(列名) 总是 ≤ COUNT(*)

这是 SQL 标准定义的行为，不是数据库 bug 或配置异常。COUNT(列名) 的语义就是“该列值不为 NULL 的行数”，只要表中存在任意一行该列为 NULL，结果就必然小于 COUNT(*)。

• 常见误判场景：COUNT(phone) 统计用户总数 → 实际只统计了填了手机号的用户
• LEFT JOIN 后对右表字段做 COUNT(right_table.id) → 匹配失败时 id 为 NULL，这部分行被完全排除
• 字段允许 NULL 且业务逻辑中显式插入了 NULL（如未激活用户的 status）→ 这些记录不会出现在 COUNT(status) 中

COUNT(*)、COUNT(1)、COUNT(列名) 三者语义差异

它们不是“写法不同但效果一样”的替代关系，而是用途截然不同的聚合表达：

• COUNT(*)：统计结果集的**总行数**，不检查任何列内容，包含所有 NULL 行
• COUNT(1)：等价于 COUNT(*)，每行生成一个非空常量 1 再计数；现代优化器（如 MySQL InnoDB）会直接重写为 COUNT(*)
• COUNT(列名)：只看指定列，遇到 NULL 就跳过，**本质是“非空值个数”而非“行数”**

验证某列有多少 NULL：可用 COUNT(*) - COUNT(列名) 直接得出。

性能和可读性建议

别为了“看起来快”而乱选函数，语义正确优先：

• 想查总行数 → 无条件用 COUNT(*)；它是 SQL92 标准，所有主流引擎都深度优化过
• 想查某列有效数据量 → 明确写 COUNT(列名)，不要用 COUNT(*) 再减差值来“模拟”
• 避免用 COUNT(1) 自欺欺人：它不比 COUNT(*) 快，也不比 COUNT(主键) 更适合索引扫描；反而容易让人误以为它和 COUNT(列名) 是同类操作
• 如果列是主键或有 NOT NULL 约束，COUNT(列名) 可能走索引更快，但这只是副作用，不能反推“应该用它代替 COUNT(*)”

最容易被忽略的点：在 GROUP BY 或带 WHERE 的复杂查询里，COUNT(列名) 的 NULL 判断是在分组/过滤后发生的——也就是说，它反映的是“当前结果集中该列的非空数量”，而不是原始表的分布。这点一旦混淆，指标就会错得无声无息。