Amazon Redshift查询Explain结果对比及临时表改派生表的性能咨询

刚好之前在Redshift里处理过类似的性能优化问题，来给你拆解一下：

一、怎么通过Explain输出对比两个查询的性能 #

Redshift的EXPLAIN（尤其是带ANALYZE的版本）能帮你精准定位两个查询的开销差异，核心要关注这几个点：

1. 用EXPLAIN ANALYZE获取真实执行数据 #

别只用EXPLAIN（它只给估算值），运行这两个命令拿到实际执行细节：

EXPLAIN ANALYZE -- 你的临时表版本查询
CREATE TEMP TABLE temp1 AS (...);
SELECT ... FROM temp1 JOIN ...;

EXPLAIN ANALYZE -- 你的派生表版本查询
SELECT ... FROM (...) AS derived1 JOIN (...) AS derived2 ...;

2. 对比核心指标 #

• 总执行时间：看输出末尾的Total execution time: X seconds，这是最直观的性能对比。
• IO开销差异：临时表版本会有明显的INSERT into temporary table或Write to temporary storage步骤，这部分是把中间结果写入磁盘的开销（哪怕是SSD临时存储也有IO耗时）；派生表是在计算节点流式处理中间结果，没有这部分写入+后续读取的IO成本，看这一步的time和bytes数值就能量化差异。
• 中间结果重复处理：如果你的临时表被多次引用（比如后续查询多次关联这个临时表），临时表只需要写一次读多次；但派生表如果被多次调用，Redshift可能会重复执行子查询（除非自动物化），看执行计划里是否有重复的扫描/计算步骤。
• 数据倾斜情况：检查Data Distribution部分，临时表如果用了不合适的DISTSTYLE可能导致数据倾斜，而派生表的分布继承自源表，看是否有Skewed标记，倾斜会大幅拖慢节点间的数据传输。

二、临时表换派生表的性能提升有多大？ #

这个没有固定数值，完全取决于你的查询场景：

• 最优场景：临时表只被引用一次：这时候提升非常明显，尤其是中间结果数据量大的时候——省去了临时表创建、写入、读取的IO开销，性能可能提升20%-60%不等（数据量越大、临时存储IO越慢，提升越显著）。而且空间上完全不占用临时存储配额，避免了临时存储满导致的查询失败。
• 注意场景：临时表被多次引用：这时候派生表可能反而变慢，因为每次引用都会重新计算子查询的结果，而临时表只需要计算一次并持久化。这种情况建议改用CTE（WITH子句），Redshift在很多场景下会自动物化CTE，平衡两者的优势。
• 其他影响因素：如果你的临时表用的是HDD临时存储（而非默认的SSD），替换成派生表的IO性能提升会更夸张；反之如果临时表数据量极小（比如几千行），提升可能微乎其微，甚至因为子查询的额外解析开销几乎看不出差异。

额外小建议 #

• 测试时尽量在相同环境下运行（比如避开业务高峰、确保源表数据量一致），避免负载波动影响对比结果。
• 如果派生表逻辑复杂，可以把它拆成CTE子句，既保持可读性，又能让Redshift优化器更好地处理中间结果。

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