LEFT JOIN 后WHERE中对右表字段加条件会使其退化为INNER JOIN；正确做法是将右表过滤条件移入ON子句，或用右表主键/外键判空来识别无匹配行。
LEFT JOIN 后 WHERE 里写了右表字段，结果变 INNER JOIN
这是最常被忽视的语义陷阱。LEFT JOIN 本意是“左表全保留”，但一旦在 WHERE 中对右表字段加非空条件（比如 WHERE r.status = 'active'），数据库会先完成连接、再全局过滤——所有右表为 NULL 的行（即没匹配上的左表行）都会被踢掉，因为 NULL = 'active' 返回 UNKNOWN，不满足 TRUE 条件。
实操建议：
- 想保留左表全部记录 + 只连右表中
status = 'active'的数据，把条件挪进ON：LEFT JOIN r ON l.id = r.l_id AND r.status = 'active' - 想查“哪些左表行没匹配上右表”，必须用
WHERE r.id IS NULL（r.id是右表主键或外键字段，不能是r.status或r.created_at这类业务字段） - 调试时先去掉
WHERE，跑一遍SELECT *，观察右表字段是否批量为NULL，确认是匹配失败还是被过滤掉了
INNER JOIN 查不到数据，先看连接字段有没有 NULL 或类型不一致
INNER JOIN 不报错也不提示，只静默跳过不匹配的行。常见原因不是 SQL 写错了，而是连接字段本身“对不上”。
实操建议：
- 检查连接字段是否含
NULL：SELECT COUNT(*) FROM t1 WHERE join_col IS NULL；任何NULL参与等值比较都返回UNKNOWN，不会被JOIN匹配 - 确认两边字段类型一致：比如左表
user_id INT，右表user_id VARCHAR且存了'123 '（带空格），123 = '123 '在多数引擎下为FALSE - 留意大小写和排序规则：MySQL 默认
utf8mb4_0900_as_cs是大小写敏感的，'ABC' = 'abc'为FALSE
WHERE 条件里用了右表字段，但该字段本身允许 NULL
比如写 WHERE r.tracking_no IS NULL 想找没发货的订单，结果却混入了“已发货但 tracking_no 没填”的脏数据——因为 tracking_no 是可空业务字段，它为 NULL 不代表“没匹配”，只代表“没填”。
实操建议：
- 筛选“无匹配”，永远优先选右表的主键或外键字段判空，例如
r.order_id IS NULL（假设order_id是右表关联左表的外键） - 如果右表是复合主键，必须全部字段一起判空：
WHERE r.a IS NULL AND r.b IS NULL - 别依赖时间字段如
r.shipped_at IS NULL，除非你 100% 确认该字段NOT NULL且业务逻辑强制必填
多表 LEFT JOIN 时，第二个 ON 引用了未定义的表字段
写 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' 实际是否生效取决于优化器——而且语义模糊：你本意是“只连 B 中 type=active 的行”，但 B 并未在前一个 ON 中被筛选过，这个条件可能被忽略或重排。
实操建议：
- 当 C 的连接逻辑依赖 B 的某个子集（比如只连
B.type = 'active'的行），必须先把 B 包一层：(SELECT * FROM b WHERE type = 'active') b - 或者用 CTE 预处理：
WITH active_b AS (SELECT * FROM b WHERE type = 'active') SELECT ... FROM a LEFT JOIN active_b ... - 记住：每个
ON只能引用它左边已出现的表，不能跨过中间表去“预读”后续表的字段
