为什么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 - 确认连接字段类型一致，避免隐式转换失败（如
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 本身，而是你不知道它在哪一层悄悄改变了语义。
