PostgreSQL VACUUM：把膨胀治理当成持续工作
背景 表持续更新之后，查询变慢和空间增长不一定靠加索引解决。旧版本清理、统计信息和长事务都可能影响维护效果。 核心判断 观察死元组估计、autovacuum 时间、事务年龄与维护进度。 区分 VACUUM 清理旧版本和 ANALYZE 更新统计信息的职责。 优先缩短长事务，再按高变化表调整阈值与维护预算。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 SELECT relname, n_live_tup, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20; 边界与误区 n_dead_tup 是估计值，不是精确计数。普通 VACUUM 通常不把空间归还操作系统；VACUUM FULL 会重写并需要强锁，不能当作无风险清理。 验证方式 对持续更新表观察维护前后的大小、计划和延迟；检查被长事务阻挡的清理效果，并评估维护对磁盘 I/O 的影响。 小结 区分 autovacuum 未跟上、长事务阻塞和表设计放大，再按表配置阈值。