LEFT JOIN查不到右表匹配项，主因是WHERE中误写右表非空条件导致左表行被过滤；正确做法是将右表筛选条件移入ON子句，查无匹配则用右表外键IS NULL判断。
LEFT JOIN 查不到右表匹配项，大概率不是数据不存在，而是过滤条件写错了位置——WHERE 里写了右表字段的非空条件，直接把本该保留的左表行给筛没了。
LEFT JOIN 后 WHERE 右表字段 = 'xxx' 会丢左表空匹配行
这是最典型的“查不到却以为没数据”的场景。LEFT JOIN 的语义是：左表所有行都保留，右表只连得上的才填值，连不上就填 NULL。但一旦你在 WHERE 里加了类似 WHERE o.status = 'paid' 这种对右表字段的判断，数据库会在连接完成后做全局过滤——而所有右表为 NULL 的行（即左表没匹配到订单的用户），NULL = 'paid' 结果是 UNKNOWN，整行就被踢掉了。
- 错误写法：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' - 正确写法：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果你真需要先连再筛（比如要统计“已支付订单数 + 未支付订单数”分开），那就得用子查询或 CTE 预处理右表，不能靠
WHERE补救
想查“哪些左表记录没匹配上右表”，必须用 WHERE 右表主键 IS NULL
这个操作看似简单，但容易选错字段。关键点在于：你得挑一个“右表本该有值、但没匹配时强制为 NULL”的字段来判空。最稳妥的是右表中用于关联的外键字段，比如 o.user_id 或 o.id。
- 安全写法：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' WHERE o.id IS NULL - 危险写法：
WHERE o.status IS NULL—— 因为o.status可能本来就是NULL（业务允许未填写状态），这时你查到的不全是“没匹配”，还混着“匹配了但状态为空”的脏数据 - 别依赖
o.created_at IS NULL这类时间字段，除非你 100% 确认右表该字段不允许NULL且必填
多表 LEFT JOIN 时 ON 条件只能引用已出现的表
当你写 A LEFT JOIN B ON ... LEFT JOIN C ON ...，第二个 ON 只能用 A 和 B 的字段，不能指望 C 能提前看到 B 经过 WHERE 过滤后的结果——因为 WHERE 是最后执行的。如果 C 的连接逻辑依赖 B 的某个筛选结果（比如只连 B 中 type = 'active' 的行），就必须把 B 先包一层子查询或 CTE。
- 错例：
A LEFT JOIN B ON a.id = b.a_id LEFT JOIN C ON b.id = c.b_id AND b.type = 'active'—— 这里b.type = 'active'实际生效，但语义模糊，且在某些优化器下可能被重排失效 - 稳写法：
WITH active_b AS (SELECT * FROM b WHERE type = 'active') SELECT ... FROM a LEFT JOIN active_b ON a.id = active_b.a_id LEFT JOIN c ON active_b.id = c.b_id - 注意：MySQL 8.0+ 支持 CTE，老版本只能用嵌套子查询，别硬套语法
真正难的不是写对第一层 ON，而是当 SQL 变长、表变多、条件变杂时，人会下意识把“业务筛选”和“连接逻辑”混在一起。只要记住一点：ON 定义“谁能连上”，WHERE 决定“哪些行留下”——中间那条线一旦划错，左表数据就悄无声息地蒸发了。
