谓词下推失效时最直接有效的解法是手动将WHERE条件挪入子查询或JOIN ON中；LEFT JOIN后WHERE过滤右表会隐式转为INNER JOIN且阻断下推，应改写为ON条件；含GROUP BY/DISTINCT/UNION ALL的子查询及视图封装也常导致下推失败，需改写SQL或展开视图。
谓词下推失效时，最直接有效的解法不是调参数或加 hint，而是把原本写在 WHERE 的条件，手动挪进子查询或 JOIN ON 中——前提是语义允许。这比等优化器“想明白”快得多。
LEFT JOIN 后 WHERE 条件导致下推失败
这是最常见也最容易踩坑的场景：把本该作用于右表的过滤条件写在 WHERE 里，结果整个 LEFT JOIN 被隐式转成 INNER JOIN，且条件无法下推到右表扫描阶段。
- 错误写法：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'→u.status在WHERE中，优化器必须先完成 JOIN 再过滤，右表全量扫描不可避免 - 正确写法：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active'→ 条件进入ON，可下推至users表扫描时提前过滤 - 注意：若右表是空表（
NULL-supplying），ON中的条件不满足时只返回NULL，语义不变；而WHERE会直接剔除整行，破坏外连接语义
子查询中含 GROUP BY / DISTINCT 时下推被跳过
数据库内核（如 Oracle、Hive、SparkSQL）普遍禁止将 JOIN 条件下推到含 GROUP BY 或 DISTINCT 的子查询内部，因为可能改变分组粒度或去重逻辑。
- 典型失效 SQL：
SELECT * FROM t1 JOIN (SELECT id, COUNT(*) c FROM t2 GROUP BY id) t2g ON t1.id = t2g.id WHERE t1.type = 'A'→t1.type = 'A'无法下推进子查询，t2全表聚合后再 JOIN - 实操建议：把外层过滤提前，改写为
SELECT * FROM t1 JOIN (SELECT t2.id, COUNT(*) c FROM t2 JOIN t1 ON t2.id = t1.id WHERE t1.type = 'A' GROUP BY t2.id) t2g ON t1.id = t2g.id - 关键点：确保
t1过滤后结果集足够小，再驱动t2关联聚合；否则考虑用临时表物化中间结果
UNION ALL 子查询中关联条件无法下推
当子查询由 UNION ALL 拼接多个分支组成时，即使每个分支都含 GROUP BY，优化器也大概率放弃下推——尤其在 MySQL 5.6、Hive 早期版本中非常顽固。
- 失效示例：
SELECT * FROM main t JOIN (SELECT id, sum(val) s FROM a GROUP BY id UNION ALL SELECT id, sum(val) s FROM b GROUP BY id) u ON t.id = u.id WHERE t.flag = 1 - 绕过方法：拆开 UNION，分别 JOIN 后再
UNION ALL：(SELECT t.*, u1.s FROM main t JOIN (SELECT id, sum(val) s FROM a GROUP BY id) u1 ON t.id = u1.id WHERE t.flag = 1) UNION ALL (SELECT t.*, u2.s FROM main t JOIN (SELECT id, sum(val) s FROM b GROUP BY id) u2 ON t.id = u2.id WHERE t.flag = 1) - 代价权衡：虽然 SQL 变长，但每个分支都能独立利用
t.flag = 1下推，避免全量扫描a和b
视图封装导致条件无法穿透
MySQL 5.6+、部分 Hive 版本对视图默认禁用谓词下推（ppd），尤其是视图定义含 JOIN、GROUP BY 或 LEFT JOIN 时，WHERE 条件基本不会进入视图内部执行。
- 验证方式：用
EXPLAIN查看table列是否出现Extra显示Using where而非Using index condition - 实操对策：不用视图，直接展开 SQL；或在支持的数据库（如 PostgreSQL、Oracle）中启用
WITH CHECK OPTION或设置set hive.optimize.ppd = true - 特别注意：MySQL 视图即使加了
ALGORITHM = MERGE，遇到GROUP BY或聚合函数仍会退化为TEMPTABLE，彻底阻断下推路径
真正难的不是“能不能下推”，而是判断“该不该下推”——有些场景下推后反而触发嵌套循环，外部驱动表大则整体更慢。实际调优时，永远以 EXPLAIN 的 rows 和 Extra 为准，而不是凭经验改写。
