LEFT JOIN后WHERE条件误用右表字段会导致左表空匹配行被过滤；ON条件遗漏引发笛卡尔积；查“缺失”需聚焦NULL行并去重；多层LEFT JOIN中各层NULL语义不同，须按业务分层处理。
LEFT JOIN 后 WHERE 条件写错，结果全空了
LEFT JOIN 本意是保留左表全部记录，但一旦在 WHERE 里对右表字段加非空判断（比如 WHERE t2.id IS NULL 以外的条件），就可能把本该保留的左表空匹配行过滤掉。本质是 SQL 执行顺序：先 JOIN，再 WHERE —— 而右表为 NULL 的行，过不了 t2.status = 'active' 这种条件。
实操建议：
- 排查异常数据时，想“找出左表有、右表无对应”的记录，必须用
WHERE t2.xxx IS NULL，且不能混其他右表字段条件 - 如果真要筛右表某状态，把条件挪到
ON子句里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 不确定时，先 SELECT * 看原始 JOIN 结果，确认
t2列是否真为NULL，再加 WHERE
ON 条件漏写关联字段，查出笛卡尔积式脏数据
LEFT JOIN 忘写 ON 或只写一半（比如只写 ON u.id = o.user_id 却漏掉时间范围），会导致左表每行和右表所有行组合，数据量爆炸，查询慢、结果不可信。
实操建议：
- 每次写
LEFT JOIN，强制自己默念一遍关联逻辑：“谁连谁？靠哪几个字段等值？有没有额外业务约束？” - 关键字段必须显式出现在
ON中，不要依赖后续WHERE补救 - 用
EXPLAIN看执行计划，若rows异常高或出现ALL类型扫描，立刻检查ON
用 LEFT JOIN 查「缺失订单的用户」，但没去重导致重复计数
一个用户可能有 0 笔订单（理想异常），也可能有 10 笔——LEFT JOIN 后，该用户会变成 10 行，其中 9 行 o.id 是真实值，1 行是 NULL。直接 COUNT 就会把这 10 行全算进去，误判为“有订单”。
实操建议：
- 查“缺失”必须聚焦
NULL行本身，用COUNT(DISTINCT u.id)或子查询先取唯一用户 ID - 更稳的做法是用
NOT EXISTS替代：SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) - 如果坚持用 LEFT JOIN，聚合前先加
GROUP BY u.id，再用HAVING COUNT(o.id) = 0
LEFT JOIN 多表嵌套时，中间表 NULL 传导被忽略
比如 users → orders → order_items，用两级 LEFT JOIN，但第二级 orders LEFT JOIN order_items 若没数据，order_items 字段全为 NULL；而第一级 users LEFT JOIN orders 仍能返回订单行。这时候你用 WHERE oi.quantity IS NULL，其实抓的是“有订单但没明细”的异常，不是“用户根本没订单”。
实操建议：
- 多层 LEFT JOIN 时，每一层的
NULL都代表不同语义，必须对照业务定义清楚哪一层的空才是目标异常 - 宁可拆成两个独立查询：先找“无订单用户”，再单独查“有订单但缺明细”的订单
- 避免写
LEFT JOIN ... LEFT JOIN ... WHERE oi.id IS NULL这类模糊条件，容易漏掉中间层已为空的情况
复杂点在于：JOIN 层级越多，NULL 的含义越容易滑动。别指望一条语句包打天下，先厘清“异常”在哪个环节发生，再决定在哪一层做拦截。
