Redshift手动分区表查询计划异常问题排查与优化诉求

背景 #

由于AWS Redshift不支持原生表分区，采用手动分区方案：将时序大表拆分为周分区表（如ifdata_detail_2022_01_31等），创建视图ifdata_detail通过UNION ALL聚合所有分区表，同时为每个分区添加固定的week_partition字段。

预期执行以下查询时，Redshift查询规划器会裁剪无用分区：

select max(day)
from ifdata_detail
where week_partition = date_trunc('week', current_date)

但实际查询耗时极长，直接查询对应分区表仅需2秒。EXPLAIN显示所有分区均被扫描，未触发分区裁剪。

后续测试发现：

• 使用常量日期替代current_date时，查询速度显著提升，且仅扫描目标分区；
• 添加day字段过滤条件后，性能也有改善；
• 通过STL_SCAN分析发现部分场景下存在裁剪，但性能表现仍有差异。

问题解答 #

1. 为何Redshift未对无用分区进行裁剪？ #

Redshift的分区裁剪依赖于查询规划阶段就能确定过滤条件的常量值。date_trunc('week', current_date)属于运行时计算的函数，查询规划器在生成执行计划时无法确定其具体值，因此无法判断哪些分区需要被裁剪，只能扫描所有分区表。

而常量日期在规划阶段就能明确值，规划器可以直接匹配对应分区表的week_partition固定值，从而跳过无关分区。

2. 如何实现仅扫描目标分区的预期行为？ #

可以通过以下几种方式实现：

• 提前计算常量值：在查询前先计算出date_trunc('week', current_date)的具体值，将其作为常量代入查询语句，比如：

  select max(day)
  from ifdata_detail
  where week_partition = '2024-05-20' -- 提前计算好的周起始日期
  

• 使用存储过程或动态SQL：通过存储过程动态生成包含常量日期的查询，确保规划器能获取到确定值进行分区裁剪；
• 添加分区表的约束条件：为每个分区表添加CHECK约束，明确week_partition的固定值（比如ALTER TABLE ifdata_detail_2022_01_31 ADD CONSTRAINT chk_week_partition CHECK (week_partition = '2022-01-31')），帮助查询规划器更准确识别可裁剪的分区；
• 改用Redshift Spectrum外部表分区：如果数据适合存储在S3上，Spectrum支持原生分区，能自动识别并裁剪分区，无需手动拆分表。

3. 为何添加组合过滤条件后性能更优？ #

添加day字段过滤后，Redshift可以利用分区表上的day字段索引（如果存在）或统计信息，先对每个分区表进行初步过滤，减少需要扫描的数据量。即使分区裁剪未完全触发，day字段的过滤也能大幅降低每个分区内需要处理的数据行数，从而提升整体查询性能。同时，查询规划器可能结合day和week_partition的关联关系，进一步优化扫描策略，减少不必要的数据读取。

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