PostgreSQL长期存活临时表：需手动VACUUM还是仅ANALYZE？

首先得给你明确一个核心事实：PostgreSQL的autovacuum守护进程完全无法访问其他会话的临时表——因为临时表是会话隔离的，只有创建它的会话能看到和操作它。你的pg_stat_user_tables结果里vacuum_count始终为0，正好验证了这一点：autovacuum根本没碰过这些临时表。

接下来针对你的问题逐一说明：

1. 必须手动执行VACUUM清理死元组 #

从你的统计数据能看到，n_dead_tup和n_tup_del数值几乎完全一致，说明你DELETE掉的所有元组都变成了死元组，完全没被清理。这些死元组会带来两个实实在在的问题：

• 浪费存储空间：死元组会一直占用磁盘空间，直到被VACUUM回收；
• 拖慢查询性能：当你查询临时表时，PostgreSQL会扫描包括死元组在内的所有数据，死元组越多，扫描的开销越大。

所以只要你对临时表有频繁的DELETE（或UPDATE，因为UPDATE本质是DELETE+INSERT）操作，就必须手动执行VACUUM来清理死元组、回收空间。

2. ANALYZE不能替代VACUUM，但仍需定期执行 #

ANALYZE的作用是更新表的统计信息，让查询优化器能生成更高效的执行计划。你已经在执行ANALYZE（analyze_count有数值），这很好，但它不会清理死元组，绝对不能替代VACUUM。

如果你的临时表数据分布变化频繁（比如频繁插入删除后，活元组的比例波动大），建议每次VACUUM后顺便执行VACUUM ANALYZE，一次性完成清理和统计更新，一步到位。

3. 额外的优化建议 #

• 按需调整VACUUM时机：比如在每次批量DELETE操作完成后立即执行VACUUM；如果是持续的小量删除，可以每天定时执行一次；
• 重构临时表使用方式：如果业务允许，与其反复DELETE临时表的数据，不如直接DROP TABLE再重新创建临时表——新表完全没有死元组，也省去了VACUUM的麻烦；
• 监控表膨胀情况：可以定期查询pg_table_size('你的临时表名')监控表的大小变化，如果大小持续增长但活元组数量没增加，说明死元组在堆积，需要及时VACUUM。

内容的提问来源于stack exchange，提问作者Андрей Щеглов