ON在连接时过滤右表，左表记录全保留；WHERE在连接后过滤整体结果，可能使LEFT JOIN退化为INNER JOIN。
LEFT JOIN 中 ON 加条件 vs WHERE 加条件结果完全不同
关键区别不在语法，而在执行阶段：ON 在生成临时表时起作用，WHERE 是对临时表生成后的最终结果过滤。对 LEFT JOIN 来说，这直接决定左表记录是否被保留。
常见错误现象：本想查“所有 HR 部门员工及其项目”，却只返回了有项目的 HR 员工——实际是把条件错写在了 WHERE 里，导致 LEFT JOIN 被隐式转成了 INNER JOIN。
-
ON a.id = b.employee_id AND a.department = 'HR'：先筛选出 HR 员工，再尝试关联项目；左表所有 HR 员工都会出现，没项目的显示NULL -
ON a.id = b.employee_id WHERE a.department = 'HR'：先做全量左连接，再从结果中只留 HR 行；看起来一样，但若右表字段参与WHERE（如WHERE b.project_name IS NOT NULL），就会彻底丢掉无项目的 HR 记录
INNER JOIN 里放 ON 还是 WHERE 真的没区别？
逻辑上等价，但语义和可维护性差很多。数据库优化器通常能重写，但不建议混用。
使用场景：纯交集查询，比如“查同时在学生表和成绩表里都有记录的学生”。
- 推荐统一写在
ON：语义清晰，表明这是连接逻辑的一部分，例如INNER JOIN scores ON students.id = scores.student_id AND scores.score >= 60 - 写在
WHERE虽然结果相同，但容易误导后续维护者以为这是“连接后过滤”，尤其当 SQL 变复杂、嵌套多层时，会模糊连接意图 - 性能影响极小，但部分旧版 MySQL 或特定执行计划下，
WHERE中的关联条件可能无法触发索引下推（index condition pushdown）
ON 后面能写非关联字段的条件吗？
能，但仅对 OUTER JOIN 有意义；对 INNER JOIN 效果等同于 WHERE，且易引发误解。
典型误用：在 LEFT JOIN 的 ON 中加右表过滤条件，例如 ON a.id = b.employee_id AND b.status = 'active'。
- 这不会过滤左表，但会让右表不满足
status = 'active'的行变成NULL—— 即：左表记录保留，右表只取活跃项目 - 如果写成
WHERE b.status = 'active'，则所有右表为NULL（即无匹配项目）的左表行都会被剔除 -
ON中混入非等值、非关联字段条件，会让执行计划更难优化，某些数据库可能放弃使用右表索引
为什么 CROSS JOIN 和 INNER JOIN 不强制要求 ON？
因为 CROSS JOIN 本意就是笛卡尔积，不需要连接条件；而 INNER JOIN 若不写 ON，多数数据库（如 PostgreSQL、SQL Server）会报错，MySQL 则允许但行为等价于 CROSS JOIN。
容易踩的坑：
- MySQL 下
SELECT * FROM a INNER JOIN b WHERE a.id = b.id语法合法，但属于历史兼容写法，语义模糊，不推荐 -
CROSS JOIN ... ON实际等效于INNER JOIN，不是标准用法，阅读成本高 - 一旦用了
OUTER JOIN（LEFT/RIGHT），ON就是强制的，漏写直接报错，不存在“退化”选项
真正复杂的地方在于：同一个条件放在 ON 还是 WHERE，不只是“结果对不对”的问题，而是“你到底想表达什么业务逻辑”。比如“查所有员工及他们的有效合同”，重点在“所有员工”（LEFT JOIN ... ON ... AND contract.status = 'valid'）；而“查有有效合同的员工”就是 INNER JOIN ... ON ... WHERE contract.status = 'valid' —— 表面相似，语义天壤之别。
