WHERE条件放错位置会导致谓词下推失效：INNER JOIN中WHERE与ON基本等价但函数或复杂表达式会阻碍下推；LEFT JOIN中右表WHERE条件会过滤NULL行、退化为INNER JOIN且禁用下推，必须移入ON子句；不等值JOIN或ON中含函数同样使下推失效。

WHERE条件放错位置，谓词根本不会下推——尤其在LEFT JOIN和不等值连接中，它可能被完全忽略。

INNER JOIN里WHERE和ON基本等价，但仍有细节差异

对INNER JOIN，优化器通常能把WHERE中单表条件（如orders.status = 'paid'）下推到对应表扫描层，也能把连接条件（如orders.id = payments.order_id）识别为可下推的ON谓词。但要注意：

• 如果WHERE里混入了计算表达式（如YEAR(order_date) = 2025），多数引擎无法下推，应改写为范围条件：order_date >= '2025-01-01' AND order_date
• ON里放连接逻辑，WHERE里放最终结果过滤；若把本该属于右表的过滤条件（如payments.amount > 100）只放在WHERE，在某些旧版MySQL中仍可能不触发下推
• 显式写进ON更稳妥：ON o.id = p.order_id AND p.amount > 100，相当于告诉优化器“右表必须先筛再连”

LEFT JOIN中WHERE条件可能彻底禁用下推

这是最常踩坑的场景。LEFT JOIN的右表是“Null Supplying Table”，它的WHERE条件一旦出现，就会把NULL行过滤掉，实际变成INNER JOIN语义，且优化器往往放弃对该右表做任何下推。

• 错误写法：LEFT JOIN order_payment p ON o.id = p.order_id WHERE p.status = 'success' → 先全量左连，再丢弃右表为NULL的行，p.status无法下推
• 正确写法：LEFT JOIN order_payment p ON o.id = p.order_id AND p.status = 'success' → 条件进入ON，右表扫描时就只读status = 'success'的行
• 如果业务真需要保留左表所有行、仅过滤右表非空匹配项，那必须接受无法下推的事实，或改用子查询预聚合右表

不等值JOIN或复杂表达式会让下推失效

像a.dt BETWEEN b.start_dt AND b.end_dt或a.name LIKE CONCAT('%', b.keyword, '%')这类条件，几乎无法下推到任一表的扫描阶段，因为它们依赖两表数据实时比对。

• 执行计划里若看到Filter节点挂在Hash Join或Merge Join之后，基本确认没下推
• 替代思路：对右表提前按时间窗口物化（如每日分区），或用LATERAL + 索引驱动的INDEX SCAN替代BETWEEN
• 避免在ON里写函数调用：ON UPPER(a.name) = UPPER(b.name) → 改为建函数索引或统一存储小写值

验证下推是否生效，别靠猜

光看SQL写法没用，必须查执行计划。重点关注扫描节点（Seq Scan、Index Scan）上是否有Filter字样，以及该Filter是否包含你写的条件。

• PostgreSQL：用EXPLAIN (ANALYZE, BUFFERS)，找Filter:行是否出现在表扫描行内
• MySQL：EXPLAIN FORMAT=TREE或EXPLAIN FORMAT=JSON，检查attached_condition和rows_examined_per_scan
• Spark SQL：EXPLAIN输出中搜索Predicate是否出现在Scan算子下，而非Filter算子

真正容易被忽略的是：不同引擎对同一SQL的下推行为可能完全不同，比如PostgreSQL 15默认启用enable_hashjoin = on且对LEFT JOIN的ON条件下推很激进，而Trino 410在CTE嵌套三层后可能直接放弃统计估算，导致下推被绕过。别假设“写了就有效”。