left join中状态过滤写在where会丢失左表无匹配记录，因where在连接后执行且筛掉右表为null的行；正确做法是将右表条件放入on子句。
LEFT JOIN里把状态过滤写在WHERE会丢数据
这是最常踩的坑：明明写了LEFT JOIN，结果却漏掉了左表中没匹配到右表的记录。根本原因是WHERE在连接完成之后才执行，一旦条件涉及右表字段（比如u.status = 1），数据库会直接筛掉所有右表为NULL的行——而这些行恰恰是LEFT JOIN本该保留的。
正确做法是把关联逻辑和右表筛选都放进ON子句：
-
ON o.user_id = u.id AND u.status = 1→ 左表订单全保留，只尝试匹配“有效用户” -
ON o.user_id = u.id WHERE u.status = 1→ 先全量连接，再筛，u.status为NULL的行被干掉
INNER JOIN里ON和WHERE通常等价，但执行计划可能不同
语义上，INNER JOIN对两边都要求匹配，所以把条件放ON或WHERE最终结果往往一样。但数据库优化器可能生成不同执行计划：
- 条件写在
ON里，可能触发更早的索引下推或连接顺序调整 - 条件写在
WHERE里，尤其涉及函数或表达式时，可能延迟过滤，导致临时结果集更大 - 用
EXPLAIN对比两者的rows和Extra字段，能直观看出差异
ON里多条件不是“AND拼接”，而是共同决定匹配逻辑
ON a.id = b.a_id AND b.type = 'order' 不等于 “先按ID连，再筛type”。它是原子性判断：只有当ID相等且type为'order'时，这两行才被认定为可连接。如果b.type不满足，这一行就完全不参与连接——对LEFT JOIN来说，左表这行仍保留，右表列全为NULL；对INNER JOIN来说，这行直接被排除。
容易混淆的点：
-
ON里的条件不会“部分生效”，它是一次性求值的布尔表达式 - 不要在
ON里写OR逻辑，多数场景下会导致笛卡尔积或性能暴跌 - 多表
JOIN时，每个ON只约束紧邻的两个表，不跨表生效
WHERE过滤右表字段时，LEFT JOIN实际退化成INNER JOIN
只要WHERE子句里出现右表的非NULL安全判断（比如u.name IS NOT NULL、u.status = 1），就等价于强制右表必须存在匹配——这和INNER JOIN的行为一致。你写的LEFT JOIN只是语法上存在，执行效果已被WHERE悄悄覆盖。
真正需要外连接语义时，必须避开这种写法：
- 用
ON+ 右表条件，保持左表完整性 - 若业务真要“只取有匹配且满足状态的记录”，直接改用
INNER JOIN，语义更清晰 - 极少数需混合逻辑（如“主表全查，右表只取有效记录，但也要显示无效记录的占位”），得用
CASE WHEN或子查询绕开
WHERE写法就立刻暴露问题。
