left join右表条件写在on中不会失效，而是控制右表参与连接的行；写在where中才会过滤左表未匹配行导致退化为inner join。
LEFT JOIN右表条件写在ON里根本不会失效
这是个常见误解。LEFT JOIN中把右表条件（比如t2.status = 'active'）写进ON子句，不是“失效”，而是**按设计工作**——它控制的是“哪些右表行参与连接”，不是“要不要保留左表行”。真正失效的是你对ON作用的理解。
为什么你看到“不符合条件的左表行也被返回”？
因为这就是LEFT JOIN的语义：左表全量保留，右表只拉符合条件的匹配行；不匹配的，右表字段全为NULL。你写的ON t1.id = t2.user_id AND t2.status = 'active'，效果是：
- 左表每行都保留
- 右表只取
status = 'active'的记录来尝试匹配 - 没匹配上的，
t2.*列就是NULL，不是被过滤掉
如果你发现王五（level = 'common'）也出现在结果里，说明ON里的s.level = 'vip'根本没拦住他——这恰恰证明它没“失效”，而是在按规则执行：这个条件只约束右表匹配逻辑，对左表无筛选作用。
真正会“失效”的是WHERE里误用右表字段
这才是高频翻车点：WHERE阶段才真正过滤最终结果集。一旦你在WHERE里写了t2.status = 'active'，所有t2.status为NULL的行（即左表没匹配上右表的那些）立刻被踢出，LEFT JOIN退化为INNER JOIN。
常见错误写法：
SELECT * FROM student s LEFT JOIN course c ON s.number = c.number WHERE c.course IS NOT NULL;
你以为在筛“有课的学生”，实际等价于INNER JOIN。正确做法是把业务意图拆清：
- 要所有学生 + 仅VIP学生的课程 →
ON s.number = c.number AND s.level = 'vip' - 要所有学生 + 只显示已选课程（不管谁选的）→
ON s.number = c.number，不加WHERE - 要查“没选课的学生” →
WHERE c.number IS NULL（唯一安全的WHERE右表判空）
ON里条件“看似无效”的真实原因
有些情况让你怀疑ON没起作用，其实是其他底层问题：
-
ON字段类型不一致（如INTvsVARCHAR）→ 触发隐式转换，索引失效，优化器放弃使用，导致全表扫描，看起来像“条件没生效” -
ON中用了函数（如UPPER(t2.email)）→ 右表索引彻底作废 - 右表字段本身大量为
NULL，而NULL = 'active'永远为UNKNOWN，自然不匹配 → 这不是ON失效，是三值逻辑的必然 - 多层
LEFT JOIN中，第二层依赖第一层的NULL字段（如t2.product_id为NULL），导致ON t2.product_id = t3.id恒不成立 → 数据链断裂，不是语法问题
最省事的验证方式：先跑SELECT *，看右表字段是否批量为NULL；再用EXPLAIN确认key和rows是否符合预期——别靠肉眼猜逻辑。
