背景

表持续更新之后，查询变慢和空间增长不一定靠加索引解决。旧版本清理、统计信息和长事务都可能影响维护效果。

核心判断

  1. 观察死元组估计、autovacuum 时间、事务年龄与维护进度。
  2. 区分 VACUUM 清理旧版本和 ANALYZE 更新统计信息的职责。
  3. 优先缩短长事务，再按高变化表调整阈值与维护预算。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

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 未跟上、长事务阻塞和表设计放大，再按表配置阈值。