谓词下推能提升性能，因其将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) = '2025-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) = 2025 改为 WHERE order_time >= '2025-01-01' AND order_time 2025-01-01'
- 优先使用SARGable（Search ARGument Able）表达式：co
l LIKE 'abc%' 可下推，col LIKE '%abc' 不可（无法利用B+树前缀索引）
- 分区表查询务必带上分区字段过滤：WHERE dt = '20250101'，让引擎直接裁剪分区目录
- Spark中开启parquet.filter.pushdown.enabled=true（默认开启），并确保Parquet文件有有效统计信息（写入时启用write.summary.enabled）
l LIKE 'abc%' 可下推，col LIKE '%abc' 不可（无法利用B+树前缀索引）