为什么SQL右表存在空值时LEFT JOIN统计的COUNT结果会严重出错

COUNT(*)统计连接后所有行，COUNT(右表字段)仅统计非NULL匹配行；右表筛选须放ON子句而非WHERE，否则LEFT JOIN变INNER JOIN；右表连接字段含NULL或类型不匹配会导致关联失败，COUNT结果失真。

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
• 确认连接字段类型一致，避免隐式转换失败（如 INT vs VARCHAR 带空格）
• 不要依赖 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 本身，而是你不知道它在哪一层悄悄改变了语义。