LEFT JOIN右表过滤条件必须写在ON中，否则WHERE中对右表字段的判断会使NULL行被剔除，导致左表数据丢失、语义退化为INNER JOIN；ON在连接阶段生效，保留左表全部记录，WHERE在连接后筛选整行。
LEFT JOIN 后的过滤条件放 ON 还是 WHERE，结果完全不同
放错位置会导致 LEFT JOIN 语义失效——本该保留的左表记录被意外过滤掉。关键区别在于：ON 在连接过程中生效，WHERE 在连接完成后再过滤。
典型错误现象：LEFT JOIN user u ON u.id = o.user_id WHERE u.status = 'active'，结果里左表 user 出现了 NULL 行，但又没看到非 active 用户，说明 active 条件实际把左表“半内连接”化了。
- 想保留所有左表记录，且只关联满足条件的右表行 → 条件写在
ON - 想先完整连接，再从结果集中筛出行 → 条件写在
WHERE -
ON中对右表字段加限制（如o.status = 'paid'）不会剔除左表行；WHERE中对右表字段加限制会直接丢弃整行（含左表数据）
INNER JOIN 下 ON 和 WHERE 效果等价，但可读性和执行计划可能不同
逻辑上，INNER JOIN 的 ON 与 WHERE 都作用于最终结果集，数据库优化器通常能等价重写。但别因此随意混用——可读性差、维护时易误判语义。
实操建议：
- 关联条件（如
u.id = o.user_id）必须放在ON - 业务过滤条件（如
o.created_at > '2025-01-01'）优先放WHERE，更符合直觉 - 某些旧版 MySQL 或特定 hint 场景下，
WHERE过滤过早可能影响索引选择，建议用EXPLAIN对比执行计划
多表 JOIN 时 ON 条件顺序和嵌套关系直接影响结果
SQL 标准中 JOIN 是左关联的：t1 LEFT JOIN t2 ON c1 LEFT JOIN t3 ON c2 等价于 (t1 LEFT JOIN t2 ON c1) LEFT JOIN t3 ON c2。这意味着 t3 的 ON 条件只能引用 t1 和 t2 的列，不能直接依赖 t3 与 t1 的关系而跳过 t2。
常见坑点：
- 写成
t1 LEFT JOIN (t2 INNER JOIN t3 ON t2.id = t3.t2_id) ON t1.id = t2.t1_id才能表达“t1 关联 t2，再以 t2 为桥梁拉 t3” - 漏掉括号或混淆结合性，可能导致
t3的ON条件无法访问预期字段，报错Unknown column 't3.xxx' in 'on clause' - MySQL 5.7+ 支持
STRAIGHT_JOIN强制连接顺序，但前提是 ON 条件本身语法正确、字段可见
WHERE 中对 NULL 的判断在 JOIN 后特别容易出错
LEFT JOIN 后右表字段为 NULL 是正常现象，但 WHERE right_table.col = 'x' 会自动排除这些 NULL 行；而 WHERE right_table.col IS NULL OR right_table.col = 'x' 才真正覆盖全集。
更隐蔽的问题是空字符串和 NULL 混用：
-
WHERE status != 'inactive'不会匹配status IS NULL的行（三值逻辑） - 需要显式写出
WHERE (status != 'inactive') OR status IS NULL，否则逻辑残缺 - 若字段定义为
NOT NULL，这个风险消失，但 JOIN 后右表字段永远可能为 NULL，不因左表约束而改变
实际写 SQL 时，最常被忽略的是：ON 条件里的字段是否真的在当前连接上下文中可见——它取决于 JOIN 的嵌套层级和别名作用域，而不是你“觉得它应该有”。调试时先确认执行计划中的 type 和 rows，再查 NULL 分布，比反复改条件更高效。
