LEFT JOIN右表过滤条件写在WHERE里会失效，是因为WHERE在JOIN之后执行，此时未匹配行的右表字段为NULL，NULL='active'结果为UNKNOWN而被过滤，导致左表空匹配行丢失。

LEFT JOIN右表过滤条件写在WHERE里会失效，是因为它让LEFT JOIN语义彻底退化成INNER JOIN——左表没匹配上的行全被过滤掉了，不是SQL引擎出错，是执行逻辑本就如此。

WHERE里写t2.status = 'active'为什么等于丢掉左表空匹配

SQL执行顺序固定：FROM → ON → JOIN → WHERE → ……。ON阶段决定“哪些右表行能跟当前左表行配对”，而WHERE是在连接完成、整行已拼好之后才执行的全局筛选。此时右表没匹配上的行，所有t2.*字段都是NULL；而NULL = 'active'在SQL中恒为UNKNOWN（不是TRUE），WHERE只保留判定为TRUE的行，于是这些行直接消失。

• 错误写法：LEFT JOIN orders t2 ON t1.id = t2.user_id WHERE t2.status = 'active' → 没订单或订单状态不符的用户全不出现
• 正确写法：LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'active' → 用户全在，只连得上且状态为active的订单才填值
• 调试线索：如果发现结果里t2.id批量为NULL，但你又期望看到左表数据，第一反应不该是查索引或数据缺失，而是检查WHERE里有没有碰t2.开头的字段

哪些条件能放WHERE，哪些必须进ON

区分标准只有一个：你想不想保留左表全部记录。

• 想保留左表全部行？右表的业务筛选（状态、时间范围、类型等）一律进ON，例如AND t2.created_at >= '2024-01-01'
• 只想查左表本身符合条件的行？比如u.age > 18，这个放心放WHERE，它不碰右表字段，不影响LEFT语义
• 真要排除右表为空的行？用WHERE t2.id IS NOT NULL是合法意图表达，不是误用——但这就不是LEFT JOIN的初衷了，不如直接用INNER JOIN更清晰
• 混合条件危险：WHERE u.status = 'active' AND t2.status = 'paid'会同时剔除左表不满足或右表不满足的行，左表完整性已不保

多层LEFT JOIN时ON条件容易漏掉的关键约束

连续LEFT JOIN三张表（如users LEFT JOIN orders LEFT JOIN order_items），第二层ON只能引用前两表字段，第三层ON若依赖第二层结果，而该结果可能是NULL，就会断链。

• 危险写法：LEFT JOIN order_items oi ON o.id = oi.order_id WHERE oi.category = 'electronics' → 没买电子产品的用户直接消失
• 正确写法：LEFT JOIN order_items oi ON o.id = oi.order_id AND oi.category = 'electronics' → 用户还在，oi字段为NULL
• 更隐蔽的坑：LEFT JOIN products p ON o.product_id = p.id，但o.product_id本身是NULL（比如订单没关联系统商品），那p.*必然全NULL——这不是bug，是逻辑必然。业务若要求“即使没订单也要带出用户偏好商品”，就得改成ON u.preferred_product_id = p.id
• 别在ON里用COALESCE(t2.status, 'inactive') = 'active'，ON阶段不支持这种NULL兜底逻辑，多数数据库会直接忽略或报错

最容易被忽略的点是：连接字段本身含NULL。比如t2.ref_id IS NULL，那么ON t1.id = t2.ref_id永远不成立（NULL = anything恒为UNKNOWN），右表字段必然全NULL——这时问题不在JOIN写法，而在数据质量或建模设计。