LEFT JOIN中右表条件应放ON而非WHERE，否则NULL值被WHERE过滤导致左表空匹配行丢失；INNER JOIN中ON与WHERE语义不同，非关联条件放ON易引发性能与结果风险。
LEFT JOIN里ON加右表条件，左表空匹配行会“意外消失”
这不是ON“失效”，而是执行顺序决定的：ON只控制右表哪些行能参与连接，不满足就填NULL；WHERE是连接完成后对整行过滤，而NULL值在WHERE o.status = 'paid'中永远不成立，整行被丢弃。结果就是本该保留的左表无匹配记录全没了，LEFT JOIN实际退化成INNER JOIN。
常见错误写法：SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'——它不会返回没订单的用户，哪怕你写了LEFT JOIN。
正确做法是把右表业务条件移进ON：ON u.id = o.user_id AND o.status = 'paid'。这样没订单或订单非paid的用户仍保留，o.*字段为NULL。
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标准保证的行为。
容易踩的坑：
- 某些老版本MySQL或Presto不支持自动下推，WHERE条件可能在连接后才执行，导致性能下降甚至结果差异
- 把
b.deleted != 1写在ON或WHERE都会漏掉b.deleted IS NULL的行（因为!=对NULL返回UNKNOWN） - 后续想把INNER JOIN改成LEFT JOIN时，原来放在ON里的业务条件必须同步调整，否则语义断裂
ON里混入非关联条件会放大中间结果集
比如LEFT JOIN orders o ON u.id = o.user_id AND o.created_at > '2025-01-01'，这个时间条件本该放WHERE，却塞进ON，会导致数据库在连接阶段无法利用索引高效筛选右表，反而可能触发全表扫描；更糟的是，如果右表有大量NULL的created_at，条件恒为FALSE，但数据库仍需遍历所有行尝试匹配。
真正该放ON的只有两类：
- 纯关联逻辑，如
u.id = o.user_id - 右表高选择性过滤（能筛掉90%以上数据），如
o.type = 'refund'，利于谓词下推减少连接基数
模糊匹配、函数表达式（如UPPER(u.name) = UPPER(o.customer_name)）一律避免放ON，它们几乎无法走索引。
多表LEFT JOIN时ON只能引用紧邻表，跨层引用会静默失效
写A LEFT JOIN B ON a.id = b.a_id LEFT JOIN C ON b.id = c.b_id AND a.category = 'vip'看似合理，但第二个ON中的a.category = 'vip'在部分数据库（如旧版MySQL）中会被忽略或报错，因为语法上C只与B直接关联，A不在其作用域内。
调试建议：
- 用
EXPLAIN看执行计划，重点关注rows和filtered值：如果改前filtered仅5%，改后升到95%，说明谓词下推生效了 - 临时加
COUNT(*) OVER (PARTITION BY a.id)观察单左表行是否关联出异常多右表行 - 每个ON子句只允许引用左侧已出现的表 + 当前右表，别指望“前面JOIN过的表已被过滤”
最常被忽略的一点：ON不是“提前过滤左表”的地方。写ON u.id = o.user_id AND u.type = 'vip'并不会筛掉非VIP用户，他们依然出现在结果里，只是不跟任何订单匹配——真要筛左表，得用WHERE。
