先说结论：COUNT 统计结果出现偏差，根本原因通常不是右表存在空值，而是你选错了 COUNT 的写法，并且没有理解它与 LEFT JOIN 在底层是如何协同的。很多开发者在看到查询结果与预期不符时，第一反应是归咎于空值——实际上，还有更隐蔽的陷阱容易被忽略。
为什么 COUNT(*) 和 COUNT(右表字段) 差异如此之大？
这两种计数方式执行的逻辑完全不同：COUNT(*) 统计的是“连接后最终生成的记录行数”，即使右表的字段全部为 NULL，它仍然会逐行计数；而 COUNT(t2.id) 只统计那些 t2.id IS NOT NULL 的行——换句话说，它仅计算“成功匹配”的记录。
看看典型的翻车场景：
- 你想统计“每个用户下了几笔订单”，顺手写了
COUNT(*)——结果呢？一个用户对应多条订单记录（或者左表一行被右表多行重复），数字直接虚高，完全不是你想要的那个数。 - 反过来，你想查“哪些用户没有下过单”，于是写了
COUNT(t2.order_id)——没下单的用户该字段是NULL，COUNT直接跳过，输出变为 0。表面上数据看起来正常，实际上零订单用户被完全遗漏。
正确的做法其实很直观：
- 统计“左表每条记录关联了多少右表中非空的记录” → 必须使用
COUNT(t2.主键)或COUNT(t2.非空字段)。 - 统计“左表本身的记录行数” → 应该使用
COUNT(*)或COUNT(t1.id)。
WHERE 里对右表字段做过滤，COUNT 结果彻底失效
当你写出 LEFT JOIN ... WHERE t2.status = 'paid'，潜意识里认为这只是在筛选已支付的订单。但实际执行效果是：所有 t2.status IS NULL 的行（也就是没有订单的用户）都会被排除——LEFT JOIN 在语义上悄无声息地变成了 INNER JOIN，COUNT 自然只统计到有支付订单的用户，零订单用户完全被忽略。
修复方法只有这一种：
- 将右表的筛选条件移到
ON子句中：LEFT JOIN orders t2 ON u.id = t2.user_id AND t2.status = 'paid' - 这样一来，即使用户没有支付订单，
t2.*所有字段均为NULL，左表的记录依然保留，COUNT(t2.user_id)结果为 0，语义才正确。
千万不要尝试 WHERE t2.status = 'paid' OR t2.status IS NULL —— 这样不仅逻辑混乱，还容易漏掉其他状态（比如 'refunded'）本应排除的情况，后续排查也会更加麻烦。
右表字段本身包含 NULL，COUNT 会静默跳过
如果右表的连接字段（比如 t2.user_id）本身就存有 NULL 值，那么 ON u.id = t2.user_id 永远不成立——因为 NULL = anything 的结果是 UNKNOWN，这些右表记录根本不会与左表产生关联。它们不会出现在结果集中，更不会被 COUNT 统计到，而你却浑然不觉。
排查时注意以下几点：
- 先检查右表连接字段是否包含
NULL：SELECT COUNT(*) FROM t2 WHERE user_id IS NULL - 确认连接字段的数据类型一致，避免隐式转换失败（例如
INTvsVARCHAR带空格）。 - 不要指望
COUNT(t2.user_id)来判断关联是否存在——它只反映“非空且匹配成功”的记录数，与右表的数据质量没有直接关系。
嵌套 LEFT JOIN + COUNT，中间断一层就全崩
举例说明：t1 LEFT JOIN (t2 LEFT JOIN t3 ON ...) ON ...。如果 t2 LEFT JOIN t3 这一层因为条件过严而没有返回任何记录，外层 t1 就只能与一堆 NULL 关联——COUNT(t3.id) 结果全是 0，表面上看数据正常，实际上中间已经断链。
安全做法：
- 拆开验证：单独运行
SELECT * FROM t2 LEFT JOIN t3 ON ...，确认有数据返回。 - 优先使用 CTE 替代子查询：
WITH t23 AS (SELECT ...) SELECT ... FROM t1 LEFT JOIN t23 ON ...，逻辑更清晰，调试也更方便。 - 避免在
ON或WHERE中对右表字段使用函数操作（比如UPPER(t2.name)），否则索引失效，匹配效率下降，也可能间接导致COUNT结果因扫描不全而出现错误。
说到底，真正棘手的从来不是 NULL 本身，而是你不知道它在哪一层悄悄改变了语义。下次遇到 COUNT 结果与预期不一致时，不妨按照这个思路逐步排查，大概率能快速定位问题根源。
