表膨胀由MVCC机制下旧版本数据未及时清理导致，频繁更新删除表易发生。通过查询n_dead_tup监控膨胀情况，核心解决方法是优化autovacuum策略，如调整scale_factor和naptime，对高频表定制参数；膨胀严重时执行VACUUM FULL或CLUSTER回收空间；定期重建索引恢复性能。预防为主，配合监控及时干预是关键。
PostgreSQL表膨胀主要是由于MVCC机制下旧版本数据未及时清理导致的，常见于频繁更新或删除的表。虽然这些“死元组”在逻辑上已不存在，但物理空间未被释放，造成存储浪费和性能下降。解决表膨胀问题，核心是合理配置自动清理策略并结合手动干预。
理解表膨胀原因
PostgreSQL使用多版本并发控制（MVCC），UPDATE和DELETE操作不会立即移除旧数据，而是标记为“可回收”。只有当VACUUM操作执行后，这些空间才可能被复用。若autovacuum未能及时运行，或设置不合理，就会导致表和索引体积持续增长。
可通过以下查询检查膨胀情况：
SELECT schemaname, tablename, pg_size_pretty(pg_table_size(schemaname||'.'||tablename)) as table_size, n_dead_tup as dead_tuples FROM pg_stat_user_tables WHERE n_dead_tup > 10000 ORDER BY n_dead_tup DESC;启用并优化autovacuum策略
autovacuum是防止膨胀的第一道防线。确保其开启，并根据业务负载调整触发阈值和频率。
- 调整autovacuum_vacuum_threshold和scale_factor：对于大表，减小scale_factor可更早触发清理。例如设为：autovacuum_vacuum_scale_factor = 0.05（即5%变更就触发）
- 提高清理频率：减小autovacuum_naptime（如设为30秒），让守护进程更频繁检查
- 针对特定表定制策略：对高频更新的表单独设置参数： ALTER TABLE hot_table SET (autovacuum_vacuum_scale_factor = 0.01);
执行手动VACUUM FULL或CLUSTER
当膨胀严重时，标准VACUUM只能标记空间可复用，无法释放回操作系统。此时需使用VACUUM FULL或CLUSTER来真正回收空间。
- VACUUM FULL：重写整个表并释放空闲页，会加排他锁，建议在低峰期执行 VACUUM FULL large_table;
- CLUSTER：按索引排序重写表，同时整理碎片，但依赖已有索引且锁定时间长 CLUSTER large_table USING index_name;
注意：这两个操作需要额外磁盘空间，且阻塞写入，务必提前评估影响。
定期重建索引
索引也会膨胀，尤其B-tree索引在大量删除后效率下降明显。定期重建可恢复性能。
- 使用REINDEX命令： REINDEX TABLE target_table;
- 或逐个重建索引避免长时间锁： REINDEX INDEX idx_name;
考虑在维护窗口执行，减少对服务的影响。
基本上就这些。关键在于预防为主，配合监控及时干预，避免膨胀到不可控程度。
