LEFT JOIN中右表条件必须写在ON里才能保留左表全量；若误放WHERE，因NULL值判定为FALSE会导致左表无匹配行被过滤，实际退化为INNER JOIN。
LEFT JOIN里对右表字段加条件，写ON还是WHERE直接决定左表行是否保留
LEFT JOIN的语义是“左表全量保留”，但这个保证只在ON阶段有效。一旦条件挪到WHERE里，数据库就先完成连接、再砍行——而右表没匹配上的行，其字段全是NULL；WHERE o.status = 'paid'这种判断遇到NULL结果恒为FALSE，整行就被丢弃。表面看是过滤订单状态，实际把没订单的用户也删了。
ON中条件只参与匹配，不影响左表行存在性
写在ON里的右表条件（比如o.status = 'paid'）是在连接时筛选右表候选行：数据库拿左表每一行，只跟右表中满足该条件的记录尝试配对；配不上？右表字段填NULL，左表那行照常输出。这正是你想要的“所有用户 + 仅已支付订单的附加信息”。
- 适用场景：统计报表、主表概览+附带筛选后的关联数据
- 注意点：
ON里用右表字段做非等值判断（如o.created_at > '2025-01-01'）可能因NULL值或索引失效拖慢性能 - 常见错误：把业务分类逻辑（如
o.type = 'vip'）误放WHERE，结果发现非VIP用户完全不出现
WHERE中对右表字段过滤会意外退化为INNER JOIN
WHERE阶段操作对象是JOIN后生成的临时表，此时右表字段要么有值、要么是NULL。WHERE o.status = 'paid'会同时剔除status不等于'paid'和NULL的行——后者正是左表无匹配时产生的。最终效果等同于INNER JOIN，但语法上你还写着LEFT JOIN，极易误导后续维护者。
- 正确做法：真要筛出“有已支付订单的用户”，就该用
INNER JOIN，语义清晰且优化器更易处理 - 例外情况：
WHERE o.id IS NULL是合理用法，专门找左表中未匹配的记录 - 多表连接时更危险：比如
A LEFT JOIN B ON ... LEFT JOIN C ON ... WHERE c.flag = 1，会干掉所有c.flag != 1或c.flag IS NULL的A-B组合，哪怕你只想保留A和B
INNER JOIN下ON和WHERE换位置通常结果一致，但逻辑不能混用
因为INNER JOIN本就不承诺保留任何一方，只返回交集，所以ON a.id = b.id AND b.deleted = 0和ON a.id = b.id WHERE b.deleted = 0多数情况下结果一样。但这只是优化器“帮忙重写”的巧合，不是SQL标准保证的行为。
- 隐患在于NULL处理：
WHERE b.deleted != 1会漏掉b.deleted IS NULL的行，ON里写同样条件也会漏——问题不在位置，在!=对NULL无意义 - 性能差异真实存在：把能大幅减少右表扫描量的条件（如
b.category_id IN (1,2,3)）放在ON里，可缩小中间结果集大小
真正容易被忽略的是执行顺序带来的隐性依赖：ON阶段右表还没被WHERE筛过，所以ON里引用右表字段做等值判断是安全的；但若在ON中写b.created_at > '2025-01-01'，而该字段存在大量NULL，就可能因索引失效或类型隐式转换拖慢整个连接过程——这比结果错更难排查。
