SQL实现带有条件筛选的JOIN查询_WHERE与ON子句的逻辑组合-SQL-PHP中文网

on 先过滤，where 后过滤；on 决定哪些行参与连接，影响中间结果集大小，where 作用于连接后的临时表，可能使 left join 退化为 inner join。

sql实现带有条件筛选的join查询_where与on子句的逻辑组合

WHERE 和 ON 的执行顺序到底谁先过滤？

JOIN 查询里加条件，WHERE 和 ON 看起来都能筛数据，但它们生效时机完全不同：后者在连接过程中起作用，前者在连接完成后再过滤。这意味着把本该写在 ON 里的关联条件错放 WHERE，可能让 LEFT JOIN 变成 INNER JOIN——这是最常踩的坑。

ON 中的条件决定「哪些行能参与连接」，影响中间结果集大小
WHERE 中的条件作用于连接后的整张临时表，会直接剔除不满足的整行（包括左表原本该保留的 NULL 行）
多表 JOIN 时，ON 是紧挨着对应 JOIN 关键字的，不能跨表引用未引入的表别名

LEFT JOIN + WHERE 条件导致丢失左表数据？

典型症状：明明用了 LEFT JOIN，结果里左表某些行却没了。问题往往出在 WHERE 子句里写了右表字段的非空判断，比如 WHERE t2.status = 'active'。这时数据库会先完成 LEFT JOIN（右表匹配不到就补 NULL），再执行 WHERE——而 NULL = 'active' 为 false，整行被干掉。

想保留左表所有行，又只取右表符合条件的部分，必须把条件挪到 ON： LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active'
如果右表条件是 IS NULL 类型（如查没关联记录的左表行），可以放心放 WHERE，比如 WHERE t2.id IS NULL
MySQL 5.7+ 对 WHERE 中右表字段的非空判断有隐式转换警告，但不会报错，容易误判

ON 子句里能用复杂表达式吗？

能，但要注意兼容性和可读性。几乎所有主流 SQL 引擎（PostgreSQL、MySQL、SQL Server）都支持在 ON 里写函数、运算符甚至子查询（只要不相关），但性能和语义容易出问题。

推荐只在 ON 里用简单等值或范围比较，比如 t1.code = UPPER(t2.code) 或 t1.ts >= t2.start_time
避免在 ON 中调用高开销函数（如 JSON_EXTRACT、正则匹配），它会在每一对连接候选行上重复执行
PostgreSQL 允许 ON 中写 EXISTS 子查询，但 MySQL 不支持；SQLite 则对非等值 ON 条件优化较差

WHERE 与 ON 混用时的执行计划怎么看？

光看 SQL 写法不够，得看执行计划里实际怎么走。不同数据库对条件下推的策略差异很大，尤其是涉及索引和统计信息时。

用 EXPLAIN（MySQL/PostgreSQL）或 SET SHOWPLAN_ALL ON（SQL Server）确认 ON 条件是否触发了索引查找，而不是全表扫描
如果 WHERE 中有左表字段的过滤（如 t1.created_at > '2024-01-01'），多数引擎会先走左表索引再 JOIN，这时候放 WHERE 反而更高效
当 ON 包含多个条件时，注意数据库是否能把所有条件都用于连接算法选择（比如 MySQL 的 Block Nested-Loop vs Hash Join）

真正难的不是语法对错，而是理解你的数据分布和引擎如何拆解这个 JOIN——同一段 SQL，在小表和大表上可能触发完全不同的执行路径。