count() - count(字段名)可直接得出该字段null行数,因count()统计所有行、count(字段名)仅统计非null行,二者之差即为null数量,语义清晰且主流数据库高效支持。

直接用 COUNT(*) - COUNT(字段名) 算 NULL 行数
想快速知道某列有多少 NULL,不用写子查询或嵌套 CASE —— 最简方式就是用总数减去非 NULL 数:COUNT(*) - COUNT(email)。这个差值就是 email 列为 NULL 的行数。它不依赖布尔表达式、不额外扫描表,语义清晰且主流数据库(PostgreSQL、MySQL 8.0+、SQL Server)都能高效执行。
-
COUNT(*)统计所有行,不管字段是不是 NULL -
COUNT(email)只统计email非 NULL 的行 - 二者相减结果恒等于
COUNT(CASE WHEN email IS NULL THEN 1 END),但更简洁 - 注意:如果该列有 NOT NULL 约束,
COUNT(*) - COUNT(email)永远是 0,别误以为查询出错
用 COUNT(CASE WHEN ... THEN 1 END) 同时查多个字段的 NULL 情况
当你要一次性看 phone、address、avatar_url 各自的 NULL 数量,写一堆 IS NULL 子查询太啰嗦。用 COUNT(CASE WHEN ... THEN 1 END) 并列写就行:
SELECT COUNT(CASE WHEN phone IS NULL THEN 1 END) AS phone_nulls, COUNT(CASE WHEN address IS NULL THEN 1 END) AS address_nulls, COUNT(CASE WHEN avatar_url IS NULL THEN 1 END) AS avatar_nulls FROM users;
- 每个
CASE只在条件成立时返回1,否则返回 NULL;COUNT()自动忽略 NULL,所以只计满足条件的行 - 不能写
COUNT(CASE WHEN phone IS NULL THEN 1 ELSE 0 END)——因为0是非 NULL 值,会被计入,结果就错了 - 如果还想统计空字符串
'',得显式加条件:CASE WHEN phone IS NULL OR TRIM(phone) = '' THEN 1 END
别把空字符串 '' 当成 NULL —— 它们在 COUNT() 里表现完全不同
COUNT(phone) 对 '' 和 ' '(带空格)完全不敏感:只要不是 NULL,哪怕内容是空串或纯空格,都会被计入“非 NULL 行”。这是 SQL 标准行为,不是 bug。
- 业务上认为“没填手机号”包含
NULL和''?那必须显式合并判断:COUNT(CASE WHEN phone IS NULL OR TRIM(phone) = '' THEN 1 END) -
COALESCE(phone, '') = ''可以统一判空,但不能直接塞进COUNT()里——COUNT(COALESCE(phone, ''))会把所有行都算进去,因为COALESCE把 NULL 转成了'',而''是非 NULL 值 - 数字或时间类型字段不存在空字符串,但可能有业务约定的“无效值”,比如
0或'1970-01-01',这些同样不会被COUNT(字段名)排除
WHERE + IS NULL 不能替代 COUNT(字段名) 的聚合逻辑
有人想“先过滤再统计”,写 SELECT COUNT(*) FROM t WHERE email IS NULL。这能得出 NULL 行数,但和 COUNT(*) - COUNT(email) 不是一个量级的事:前者强制走一次全表或索引扫描过滤,后者可能复用已有聚合路径(尤其在带 GROUP BY 的场景下)。
- 单次查询差别不大;但在分组统计中,
GROUP BY category下同时要COUNT(*)和COUNT(email),比写两个带WHERE的子查询快得多 -
WHERE email IS NULL能否走索引,取决于索引定义。MySQL 单列 B-tree 索引默认不存 NULL,所以很可能回表;而COUNT(email)在优化器眼里只是跳过 NULL 标记,开销更低 - 真正容易被忽略的是:ORM 或低代码平台生成的 SQL,常把前端传来的空字符串自动转成
NULL插入,或者反过来——导致你查IS NULL查不到,但COUNT(email)又没计入,数据对不上
实际跑的时候,最常踩的坑不是语法写错,而是混淆了「SQL 层的 NULL」和「业务层的空」。一个字段到底哪些值该算“无数据”,得先在表设计或清洗阶段定清楚,不然 COUNT 写得再对,结果也和业务预期不符。











