LEFT JOIN中ON条件过滤右表不丢失左表行，WHERE条件则可能因右表字段为NULL而过滤掉左表行；正确做法是将右表业务条件放ON，全局筛选放WHERE。
LEFT JOIN 中 ON 条件过滤右表，不会丢左表行
ON 子句在连接阶段起作用，它只决定「右表哪些行能跟左表某行配对」。只要左表有数据，不管右表有没有匹配、匹配上几个、匹配的行是否满足额外条件，左表这行都一定出现在结果里——没匹配上的右表字段全为 NULL。
常见错误现象：想查所有员工，但只关联“在职”状态的部门信息，却把 department.status = 'active' 写在 WHERE 里，结果没部门或部门不活跃的员工直接消失了。
- 正确写法：
LEFT JOIN department d ON e.dept_id = d.id AND d.status = 'active' - 这样：员工全在，只有 status 是 'active' 的部门才被拉进来；其他员工的部门字段为
NULL - 性能影响：ON 中加条件可减少右表参与连接的行数，通常比 WHERE 更早剪枝，执行更快
LEFT JOIN 中 WHERE 条件会全局过滤，可能变相变成 INNER JOIN
WHERE 在 LEFT JOIN 完成后才执行，它面对的是已经拼好的临时大表。一旦 WHERE 条件里引用了右表字段（比如 d.name、d.id），而该字段值是 NULL（即左表某行没匹配到右表），那整行就会被干掉。
典型陷阱：用 WHERE d.name = '技术部' 看似想筛选部门名，实则把所有没匹配到“技术部”的员工（包括没部门的）全踢出结果。
- 错误写法：
WHERE d.name = '技术部'→ 实际等效于INNER JOIN ... WHERE ... - 若真要筛出“有技术部归属”的员工，应明确接受丢失无部门者，否则改用 ON
- 唯一安全用右表字段做 WHERE 判断的场景是
IS NULL，例如WHERE d.id IS NULL查无部门员工
ON 和 WHERE 混用时，执行顺序不可颠倒
SQL 逻辑执行顺序固定为：FROM → JOIN + ON → WHERE → GROUP BY → SELECT → ORDER BY。这意味着 ON 先跑、WHERE 后跑，二者不能互换语义。
容易踩的坑：有人以为“反正都要过滤，放哪儿都一样”，但在 LEFT JOIN 下，放错位置会导致行数从 N 变成远小于 N，且很难通过肉眼数据发现（尤其当右表匹配率高时）。
- 示例对比：
SELECT * FROM orders o LEFT JOIN customers c ON o.cid = c.cid AND c.country = 'China' WHERE o.amount > 100
→ 所有订单保留，只连中国客户，再筛金额；SELECT * FROM orders o LEFT JOIN customers c ON o.cid = c.cid WHERE c.country = 'China' AND o.amount > 100
→ 先连所有客户，再筛 country='China'，结果中没有中国客户的订单直接消失 - 调试建议：先去掉 WHERE，看 LEFT JOIN 原始结果中右表字段是否大量为
NULL；再加 WHERE，观察行数是否骤减
INNER JOIN 下 ON 和 WHERE 效果相同，但语义和效率仍有差异
虽然对最终结果集没影响，但写法仍暴露意图并影响执行计划。ON 更贴近“连接逻辑”，WHERE 更贴近“业务筛选”。数据库优化器可能因写法不同选择不同索引或连接算法。
实际开发中，建议把纯粹用于关联的条件（如 a.id = b.a_id）放 ON，把业务规则类条件（如 b.status = 'valid'、a.created_at >= '2025-01-01'）统一放 WHERE —— 这样 LEFT JOIN 改 INNER JOIN 时更安全，也便于后续加权限控制或动态 SQL 拼接。
- 例外：当右表条件能大幅减少连接基数时（比如右表千万行，加
type = 'urgent'后只剩百行），强制写进 ON 可显著提速 - 别依赖“效果一样”就混写，LEFT JOIN 一旦混进 WHERE 就容易漏数据，这是线上事故高频点
真正难的不是记住规则，而是每次写 LEFT JOIN 时下意识问一句：我到底想保留左表全部，还是只想要“连得上且满足某条件”的子集？这个问题的答案，直接决定条件该塞进 ON 还是 WHERE。
