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嵌套三层后可能直接放弃统计估算，导致下推被绕过。别假设“写了就有效”。
