Redshift动态查询S3日期分区数据：哪种方法高效低成本？

我们的场景是：S3存储桶按dt=YYYY-MM-DD格式分区，通过Redshift查询最近2天的数据，必须通过dt过滤来控制扫描成本。下面直接对比三种写法的优劣，再给出更优方案：

三种写法的性能与成本分析 #

1. 直接在WHERE子句中计算日期 #

SELECT ... FROM src WHERE dt >= CAST(DATEADD(day, -1, GETDATE()) AS DATE)

这是三种里最快、成本最低的写法。Redshift查询执行时会把GETDATE()计算成一个固定常量，优化器能直接识别这个过滤条件，触发分区裁剪（Partition Pruning），只扫描符合条件的S3分区，没有额外的临时表创建或关联开销，执行计划最简。

2. 临时表存日期+子查询引用 #

CREATE TEMPORARY TABLE var AS (SELECT CAST(DATEADD(day, -1, GETDATE()) AS DATE) AS yday);
SELECT ... FROM src WHERE dt >= (SELECT yday FROM var)

这种写法多了临时表的创建步骤——虽然临时表只有一行数据，但还是会增加少量初始化和读取开销。Redshift优化器大多能识别子查询返回的是常量值，最终还是会做分区裁剪，但整体性能和成本比第一种略高，属于没必要的额外操作。

3. 临时表存日期+JOIN关联 #

CREATE TEMPORARY TABLE var AS (SELECT CAST(DATEADD(day, -1, GETDATE()) AS DATE) AS yday);
SELECT ... FROM src JOIN var ON src.dt >= var.yday

这是三种里最差的选择。JOIN操作会干扰Redshift的分区裁剪判断（尤其是优化器把临时表视为动态数据集时），可能导致扫描更多不必要的S3分区，直接增加成本。而且JOIN本身的开销比简单WHERE过滤大，性能也更差。

更优替代方案 #

方案一：使用会话变量复用日期 #

如果需要在同一会话中多次使用这个日期条件，可以用会话变量替代临时表，避免临时表的额外开销：

SET yday = CAST(DATEADD(day, -1, GETDATE()) AS DATE);
SELECT ... FROM src WHERE dt >= current_setting('yday')::DATE;

这种写法和第一种性能接近，同时支持日期值的复用，适合多步骤查询场景。

方案二：脚本层面提前计算日期（适合定时任务） #

如果是自动化定时脚本（比如Shell、Airflow任务），可以在脚本里提前计算好目标日期，再传入Redshift查询：

# Shell脚本中计算昨天的日期
YDAY=$(date -d "yesterday" +%Y-%m-%d)
# 将日期作为参数传入Redshift查询
psql -h your-redshift-host -U your-user -d your-db -c "SELECT ... FROM src WHERE dt >= '$YDAY'"

这种方式让查询中的日期是固定字符串，Redshift优化器能100%确定分区范围，分区裁剪最彻底，完全避免查询时的日期计算开销，成本和性能都是最优的，适合定时执行的批量查询任务。

内容的提问来源于stack exchange，提问作者Ms.Lis