谓词下推能提升性能，因其将 WHERE 过滤提前至数据读取阶段，减少全表扫描、中间数据量及网络传输；支持下推的条件包括基础比较、范围匹配、空值判断及简单函数包裹列，而含 NOW()、子查询等不可下推。
谓词下推（Predicate Pushdown）是 SQL 查询优化中的关键技术，核心思想是把过滤条件尽可能提前到数据读取阶段执行，减少中间结果集大小，从而降低 内存占用、网络传输和后续计算开销。
为什么 谓词下推能提升性能
在没有谓词下推的执行流程中，数据库可能先扫描全表、完成连接或聚合，再应用 WHERE 条件过滤——这意味着大量无关数据被加载、传输甚至参与计算。而谓词下推让存储层（如 Parquet 文件、MySQL 索引、Spark 数据源）在读取物理数据时就跳过不满足条件的数据块或行组。
- 对带索引的列（如 MySQL 主键、B+ 树索引字段），下推后可直接走索引 Range Scan，避免全表扫描
- 对列存格式（如 Parquet、ORC），可利用统计信息（min/max、bloom filter）跳过整个 Row Group
- 在分布式引擎（如 Spark、Presto）中，下推能显著减少 Shuffle 和 Executor 间数据传输量
哪些条件支持下推：常见可下推谓词
并非所有 WHERE 子句都能被下推。数据库优化器会根据算子语义、数据源能力及统计信息判断可行性。以下条件通常可下推：
- 基础比较：col > 100、col = ‘abc’、col IN (1,2,3)
- 范围匹配：col BETWEEN 10 AND 20、col LIKE ‘prefix%’
- 空值判断：col IS NULL、col IS NOT NULL（部分引擎支持）
- 简单函数包裹列：date(col) = ‘2024-01-01’（若底层支持该函数下推）
注意：含不可下推函数（如 NOW()、RAND()、子查询、复杂 UDF）、跨表表达式（t1.a + t2.b > 100）或窗口函数通常阻断下推。
如何验证谓词是否真正下推
不能只看 SQL 写了 WHERE，要确认执行计划中过滤动作发生在 Scan 节点而非 Filter 节点。
- MySQL：用 EXPLAIN 查看 type、key、rows，key 非 NULL 且 rows 明显小于表总行数，说明索引已用于过滤
- Spark SQL：EXPLAIN FORMATTED，查找带有 PushedFilters 的 FileScanRDD 或 Scan 关系，如 PushedFilters: [IsNotNull(age), GreaterThan(age,18)]
- Presto/Trino：EXPLAIN (TYPE DISTRIBUTED)，观察 TableScan 节点下的 ”Constraint” 字段是否包含简化后的谓词
如果过滤出现在 Exchange 或 Project 之后的 Filter 算子中，说明未下推成功，需检查条件写法或数据源配置。
手动优化：引导谓词下推的实用技巧
优化器有时因统计信息陈旧、表达式复杂或配置限制未能自动下推。可通过以下方式增强下推概率：
- 避免在过滤列上使用函数：把 WHERE YEAR(order_time) = 2024 改为 WHERE order_time >= ‘2024-01-01′ AND order_time 2025-01-01’
- 优先使用 SARGable（Search ARGument Able）表达式：col LIKE ‘abc%’ 可下推，col LIKE ‘%abc’ 不可（无法利用 B + 树前缀索引）
- 分区表查询务必带上分区字段过滤：WHERE dt = ‘20240101’，让引擎直接裁剪分区目录
- Spark 中开启 parquet.filter.pushdown.enabled=true（默认开启），并确保 Parquet 文件有有效统计信息（写入时启用 write.summary.enabled）
