分区表日期过滤优化：范围过滤与仅下限过滤的查询效率对比

首先需要先澄清一个前提：你给出的两段SQL逻辑并不等价，本身扫描的数据范围就有区别：

• 第一种写法仅限定了日期下限，会返回所有date >= 2021-09-01的分区数据，如果你的表中存在2021-10-01之后的分区，这段SQL扫描的分区数会远多于第二种写法，执行速度自然会明显更慢。
• 第二种写法用between限定了明确的起止区间，只会扫描2021-09-01到2021-10-01之间的分区。

如果我们把两段SQL的逻辑对齐，比如把第一种写法也补全上限条件date >= date_sub('2021-10-01',interval 30 day) and date <= '2021-10-01'，再对比性能的话，绝大多数主流支持分区裁剪的数据库（包括BigQuery、Hive、Spark SQL、PostgreSQL、MySQL 8.0+等）中，两种写法性能几乎没有差异，核心原因如下：

• 所有成熟的查询优化器都会将between A and B等价转换为>= A and <= B的逻辑，执行阶段会做完全一致的分区裁剪，最终的执行计划完全相同，不会有性能区别。
• 对于第一种写法里的date_sub函数计算，主流优化器都支持常量折叠规则，会在查询解析阶段就提前计算出date_sub('2021-10-01',interval 30 day)的静态结果2021-09-01，不会影响分区裁剪的触发。

只有两种极端场景下会出现性能差异：

• 你使用的数据库优化器版本非常老旧，不支持常量折叠，无法识别函数计算后的分区过滤值，导致无法触发分区裁剪、全表扫描，这时候第一种写法的性能会远差于直接写固定区间的第二种写法。
• 表的分区键存在大量异常值、空值，优化器统计信息严重不准，导致分区裁剪的范围判断出现偏差，不过这种场景出现概率极低，差异幅度也很小。

实践建议 #

如果你的查询逻辑就是要获取固定时间区间的数据，更推荐直接写清楚起止范围，一方面可以避免后续表新增数据后，查询到不需要的新分区，另一方面也能进一步降低优化器判断失误的概率。

内容的提问来源于stack exchange，提问作者HybridFenix