Redshift批量INSERT INTO SELECT执行过慢问题排查求助

咱们先来拆解你遇到的问题：明明只筛选1000行数据，却花了50分钟，而且执行计划显示是全表扫描——这就是核心症结所在，下面给你逐一分析原因：

1. 排序键（SORTKEY）没发挥作用，触发了全表扫描 #

你提到creation_date是SORTKEY之一，但执行计划里的XN Seq Scan说明数据库压根没用到这个排序键来做范围扫描，反而遍历了整个2.86亿行的大表。常见原因有这几个：

• 统计信息过时：如果很久没更新old_table的统计信息，数据库优化器不知道creation_date的数据分布，可能错误判断全表扫描比范围扫描更快。
• SORTKEY是复合键且顺序不对：如果creation_date是复合SORTKEY的非首列（比如SORTKEY是(other_col, creation_date)），单独对creation_date做范围查询是没法利用排序键的有序性的。
• 数据分布严重倾斜：如果old_table的数据在分片上分布极不均匀，某个分片集中了绝大多数数据，优化器可能会放弃范围扫描，直接选择全表扫描。

2. 大表全表扫描的开销远超想象 #

你的old_table有400列，属于宽表，每一行的数据量本身就很大。全表扫描需要读取所有数据块，哪怕最后只筛选出1000行，磁盘IO的压力已经拉满了——尤其是磁盘空间本来就不足的情况下，IO性能可能会进一步下降，导致耗时剧增。

3. 目标表new_table的配置可能拖后腿 #

如果new_table没有设置合适的DISTKEY、SORTKEY，或者开启了外键约束、触发器，插入数据时会额外增加数据重分布、排序或者校验的开销，进一步拉长执行时间。

给你几个优化方向试试： #

• 先更新统计信息：执行ANALYZE old_table;，让优化器拿到最新的数据分布，大概率能让它选择正确的范围扫描。
• 调整SORTKEY定义：确保creation_date是单独的SORTKEY，或者是复合SORTKEY的第一列，这样范围查询才能用上排序键的优势。
• 用UNLOAD+COPY替代INSERT SELECT：对于这类数据仓库场景，COPY命令的效率远高于INSERT SELECT。可以先把筛选出的数据用UNLOAD导出到存储，再用COPY导入到new_table。
• 缩小分批时间范围：比如每次只取一周的数据，单次扫描的数据量小了，耗时自然会降低。
• 检查new_table的配置：确保它的DISTKEY和SORTKEY设置合理，关闭不必要的约束和触发器，减少写入时的额外开销。

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