UNION ALL（尤其配合GROUP BY）导致谓词无法推入，因语义等价性难以保证，优化器放弃下推，常见全表扫描；MySQL 5.6/5.7、openGauss 6.0.1等明确不支持，hint常被忽略，实操建议拆分查询或改用CTE+显式过滤。
视图定义含 UNION ALL 时谓词无法推入
当视图里用了 UNION ALL（尤其是配合 GROUP BY），优化器基本放弃谓词推入。不是它不想，是逻辑上难以保证语义等价——比如两个子查询分别聚合后合并，外部 WHERE 条件若下推到任一子查询，可能漏掉另一侧本该满足条件的行。
常见错误现象：外层加了 WHERE agent_id = 123，但执行计划里仍对 QUERY_DES 和 QUERY_OLD 全表扫描。
- MySQL 5.6/5.7、openGauss 6.0.1 等版本明确不支持此类推入
- PostgreSQL 虽能部分推入，但遇到
LATERAL或窗口函数也会退化 - 别指望加
/*+ PUSH_PRED */hint 解决，这类结构下 hint 常被忽略
实操建议：把 UNION ALL 拆成两段独立查询，在应用层或存储过程里分别加过滤；或者改用 CTE + UNION ALL 并显式在外层 WHERE 中重复过滤字段（虽然冗余，但能触发索引）。
视图算法为 TEMPTABLE 时必然阻断下推
SHOW CREATE VIEW view_name 若显示 ALGORITHM=TEMPTABLE，说明视图结果会先物化成临时表，之后再对外部 WHERE 过滤——此时谓词根本不可能下推到底层表。
原因很直接：临时表已脱离原始表结构，优化器看不到底层列与索引关系。
- MySQL 默认对含
GROUP BY、DISTINCT、聚合函数、子查询的视图设为TEMPTABLE -
ALGORITHM=MERGE才可能下推，但需满足“可合并性”：不能有不可下推的表达式、不能跨库、不能含用户变量 - 某些版本（如 MySQL 5.6）即使声明
ALGORITHM=MERGE，实际执行时仍悄悄降级为TEMPTABLE
实操建议：用 EXPLAIN 看执行计划中是否出现 <derivedn></derivedn>；若出现，就说明走的是临时表路径，必须重构视图逻辑或改用物化表/基础表直查。
JOIN 中的 ON 条件与 WHERE 条件混用导致推入失效
在视图定义里写 LEFT JOIN t2 ON t1.id = t2.id AND t2.status = 'active'，和外层 WHERE t2.status = 'active' 是两回事。后者在 LEFT JOIN 后才生效，而优化器无法把该条件安全地下推到 t2 的扫描阶段，否则会破坏 LEFT JOIN 语义（即右表无匹配时仍要保留左表行）。
典型错误：以为加了 WHERE t2.status = 'active' 就能走 t2 上的索引，结果发现 t2 还是全表扫。
- LEFT JOIN 的 ON 后条件才可能被下推（且仅限于能保证语义不变的等值条件）
- WHERE 中涉及右表的非空条件，等价于把 LEFT JOIN 降级为 INNER JOIN，但优化器不一定自动识别并改写
- Spark SQL 在此场景下更激进：若推入会导致结果不一致，会直接禁用下推（见执行计划中 filter 出现在 join 后）
实操建议：把本该属于 ON 的过滤条件（尤其是关联键+状态组合）直接写进视图的 JOIN 子句；避免在调用视图时补 WHERE 去“修正”语义。
UDF 或复杂表达式让优化器放弃推理
视图里用了自定义函数（如 SF_GET_EQP_TYPE(t1.eqp_type_id)）、CASE WHEN、嵌套子查询，优化器往往无法判断其是否可下推。尤其当函数体不可内联、或含副作用时，优化器宁可保守处理——先算完再过滤。
后果不只是性能差：还可能引发运行时报错，比如 sqrt(a) 在 a 为负时提前计算，而本该由 WHERE a > 0 先拦住。
- openGauss、Oracle 等对 UDF 推入支持极弱，基本视为黑盒
- MySQL 对内置函数（如
IFNULL、CONCAT）有一定推入能力，但一旦混入用户函数就立即失效 - Spark SQL 中，UDF 下推失败常表现为 task 卡在 filter 阶段，日志里反复出现 “filtering ORC stripe”
实操建议：把 UDF 拆成基础字段+应用层处理；或在视图外层显式补上能覆盖函数输入范围的前提条件（例如 WHERE eqp_type_id IS NOT NULL AND eqp_type_id > 0），帮优化器建立安全边界。
谓词下推失效很少是单一原因，通常是视图结构、数据库版本、表达式复杂度三者叠加。最稳妥的做法不是调参数，而是用 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或 EXPLAIN FORMAT=JSON（MySQL）看真实执行路径——有没有 Filter 出现在 Table Scan 内部，比任何文档都准。
