Redshift每日手动VACUUM单表耗时2小时是否正常及对并发查询的影响

单表VACUUM耗时2小时是否正常，核心取决于以下几个关键因素：

• 表的规模与数据变化频率：如果是TB级别的大表，且日常有频繁的DELETE、UPDATE操作（Redshift的UPDATE是逻辑删除，会产生大量旧版本数据），2小时的耗时完全在合理范围内。这类场景下VACUUM需要完成数据重排、删除标记清理等大量IO密集型操作，数据量越大、碎片化越严重，耗时自然越长。
• 集群资源状态：如果执行VACUUM时集群正处于高负载（比如有大量并发查询在运行），CPU、IO资源被争抢，VACUUM的执行速度会被拖慢，进而拉长耗时。
• VACUUM操作类型：Redshift的VACUUM有不同模式，VACUUM FULL会彻底清理所有删除数据并重新排序全表，耗时远高于VACUUM SORT ONLY或VACUUM DELETE ONLY。如果你的操作是VACUUM FULL，大表耗时2小时是正常现象。

VACUUM操作对并发查询的影响主要体现在两个层面：

• 锁冲突：Redshift的VACUUM会持有共享锁，这意味着它不会阻塞读操作（SELECT可以正常执行），但会完全阻塞写操作（INSERT、UPDATE、DELETE）。如果业务在VACUUM期间需要对目标表写入数据，这些写请求会被排队，直到VACUUM完成。
• 资源抢占：VACUUM是IO密集型操作，会占用大量集群的磁盘IO和CPU资源。如果VACUUM持续2小时，期间的并发查询会和它争抢资源，导致查询执行时间变长，甚至出现队列等待的情况——尤其是IO带宽不足的集群，影响会更明显。
• 优先级影响：如果集群配置了查询队列管理，VACUUM的默认优先级为中等，高优先级的查询会优先获得资源，但如果VACUUM已经占用了大部分IO，高优先级查询的性能还是会受到一定影响。

• 不要盲目每日全量执行VACUUM，通过SVV_TABLE_INFO系统视图查看表的unsorted（未排序比例）和deleted（已删除数据比例），只对碎片化严重（比如unsorted>20%、deleted>10%）的表执行操作。
• 选择业务低峰期执行VACUUM，避免和高并发查询、写入操作冲突。
• 根据需求选择针对性的VACUUM模式：如果只需要清理删除数据，用VACUUM DELETE ONLY；如果只需要排序，用VACUUM SORT ONLY，这两种模式的耗时远低于全量VACUUM。

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