不能。ON条件在LEFT JOIN中只控制右表匹配行为，不剔除左表行；WHERE条件则在连接后过滤，会使左表无匹配记录被彻底排除。
ON子句里加状态过滤，真的能替代WHERE吗？
不能。在 LEFT JOIN 中把状态条件写进 ON 子句，和写在 WHERE 后，语义完全不同——前者影响连接逻辑，后者影响最终结果集。很多人误以为“只要加了 status = 'active' 就能筛出活跃关联数据”，结果发现左表记录莫名丢失，根源就在这里。
LEFT JOIN + ON 中的状态条件，到底怎么生效？
它只控制「哪些右表行能被连上来」，不剔除左表行。比如 LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'shipped'：每个用户都会保留，但只有订单状态为 shipped 的才填入订单字段；其他订单（如 pending）被忽略，对应字段为 NULL。
- 适合场景：统计每个用户有多少已发货订单（
COUNT(orders.id)），同时保留无发货订单的用户 - 错误用法：想排除所有非
shipped订单后做聚合，却用WHERE orders.status = 'shipped'——这会让没发货的用户彻底消失 - 注意：如果右表有多个满足
ON条件的行，依然会生成多行（即不会自动去重）
INNER JOIN 里 ON 加状态和 WHERE 加状态效果一样吗？
逻辑结果通常一致，但执行计划可能不同。数据库优化器大概率会把 INNER JOIN ... ON ... AND status = 'X' 和 INNER JOIN ... ON ... WHERE status = 'X' 重写成相同计划，但不能依赖这点。
-
ON中写状态：更清晰表达业务意图——“我只关心状态为 X 的关联关系” -
WHERE中写状态：可能被误解为“先全量连接再过滤”，尤其当后续还有其他WHERE条件时，可读性下降 - 隐患：如果误写成
LEFT JOIN却用WHERE过滤右表字段（如WHERE orders.status = 'shipped'），会退化为INNER JOIN，且难以排查
多表连接时，状态条件放错位置会导致什么？
常见翻车点：第三个表的状态条件本该约束它自己，却错放到前一个 ON 子句里，造成笛卡尔积或漏数据。
例如：FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN items i ON o.id = i.order_id AND i.is_deleted = false ✅ 正确——is_deleted 是 items 自身状态，理应在它参与连接时限定。
反例：... LEFT JOIN items i ON o.id = i.order_id AND o.status = 'shipped' ❌ 错了——o.status 是订单状态，不该在 items 的连接条件里重复判断，既冗余又易引发歧义。
复杂点在于：当连接链变长、状态条件跨层级时，必须逐层确认「这个条件属于哪张表、想约束的是连接行为还是最终结果」——漏掉这一层判断，查出来的数据就 quietly 错了。
