count(*)统计所有行数，count(列名)仅统计该列非null值，故结果常不同；空字符串不等于null，仍被count(列名)计入。

为什么 COUNT(*) 和 COUNT(列名) 返回结果经常不一样

根本原因在于二者统计的对象不同：COUNT(*) 统计的是行数，不管字段是否为 NULL；而 COUNT(列名) 只统计该列非 NULL 的值。只要表中存在任意一列含 NULL，两者结果就可能不等。

常见错误现象：明明查了 100 行数据，COUNT(*) 返回 100，但 COUNT(email) 却只返回 87——说明有 13 条记录的 email 是 NULL 或空字符串（注意：空字符串 '' 不是 NULL，仍会被 COUNT(email) 计入）。

• COUNT(*) 是最轻量的行计数方式，优化器通常不实际读取列数据，性能最好
• COUNT(列名) 必须检查该列每行的值是否为 NULL，涉及列扫描，尤其对未索引的大文本列可能稍慢
• 如果列有允许 NULL 的约束（如 email VARCHAR(255) NULL），就要特别警惕 COUNT(email) 漏计

COUNT(1)、COUNT(*) 和 COUNT(主键) 到底有没有区别

在绝大多数主流数据库（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）中，COUNT(*)、COUNT(1) 和 COUNT(主键) 在语义和执行计划上几乎等价，都用于统计行数。但细节仍有差异：

• COUNT(*) 是 SQL 标准写法，明确表达“统计所有行”，语义最清晰，推荐首选
• COUNT(1) 是历史遗留习惯，某些旧版 MySQL（如 5.6）曾对 COUNT(1) 做过微小优化，但现代版本已无实质差别；不过它容易让人误解为“统计值为 1 的行”
• COUNT(id)（假设 id 是 NOT NULL 主键）逻辑上等效，但如果该列定义允许 NULL（哪怕实际没数据为 NULL），数据库仍会做 NULL 检查，理论上略重

示例验证：

SELECT COUNT(*), COUNT(1), COUNT(id) FROM users WHERE status = 'active';

—— 三者结果一致，执行计划中的 rows read 和 cost 也基本相同。

想统计“非空且非空白字符串”的数量，不能只靠 COUNT(列名)

COUNT(列名) 只过滤 NULL，不处理空字符串 ''、纯空格 ' ' 或其他业务意义上的“无效值”。这是高频踩坑点。

• 错误写法：COUNT(phone) → 会把 ''、' ' 都算进去
• 正确写法：配合 CASE 或布尔表达式，例如

  SELECT COUNT(CASE WHEN TRIM(phone) != '' THEN 1 END) FROM users;

• 更简洁（支持 PostgreSQL / MySQL 8.0+ / SQL Server）：

  SELECT COUNT(*) FILTER (WHERE TRIM(phone) != '') FROM users;

  （PostgreSQL）或用 SUM 模拟：

  SELECT SUM(IF(TRIM(phone) != '', 1, 0)) FROM users;

GROUP BY 场景下混用 COUNT(*) 和 COUNT(列名) 容易误读业务含义

在分组聚合中，两者的差异会被放大，且直接影响指标解读。比如分析各城市用户注册情况：

SELECT city, COUNT(*), COUNT(email) FROM users GROUP BY city;

这里 COUNT(*) 是“该城市的总用户数”，而 COUNT(email) 是“该城市留了邮箱的用户数”。若某城市 COUNT(*) = 50 但 COUNT(email) = 5，说明 90% 用户未填邮箱——这可能是产品漏斗问题，而非 SQL 写错了。

• 务必在 SELECT 列别名中明确标注含义，如 COUNT(*) AS total_users、COUNT(email) AS users_with_email
• 避免在同一个查询里无说明地并列两个 COUNT，尤其当列名本身不具业务自解释性（如 COUNT(col3)）
• 如果目标是“每个城市至少填了一项联系方式的用户数”，就得用 COUNT(CASE WHEN phone IS NOT NULL OR email IS NOT NULL THEN 1 END)

真正容易被忽略的是：NULL 的判定发生在 GROUP BY 分组之后，所以每个分组内的 NULL 过滤是独立进行的——这个行为在嵌套子查询或窗口函数中会进一步复杂化。