PostgreSQL Vacuum 死锁运行手册

要解决什么问题

autovacuum 跟不上写入速度时，表里的死元组持续堆积，索引膨胀，查询计划越来越差；此时若再遇到一个持有旧快照的长事务，VACUUM 会被反复阻断，cleanup 无法推进，整张表陷入「越扫不完越膨胀」的循环。运维人员需要快速回答：哪些表膨胀最严重、是哪个会话在拖住 vacuum、该如何安全处理这个长事务。靠人工逐张翻 pg_stat_user_tables 和 pg_locks 排查，耗时且容易遗漏。

它如何工作

• 通过 pg_stat_user_tables 汇总各表的死元组数量与膨胀趋势，圈定最需要关注的候选表
• 结合 pg_locks 与 pg_stat_activity，定位阻塞 vacuum 的长事务及其持有的锁
• 使用 pgstattuple 扩展对候选表做实际空间测量，确认真实膨胀比例，避免误判
• 针对长事务冲突生成可执行的补救 SQL，而不是只给出诊断结论

适用边界

• 需要目标实例已安装 pgstattuple 扩展，且运行账号具备相应权限
• 底层基于 node-postgres，要求环境中可使用 npm install pg；纯 JavaScript 实现，可选原生 libpq 绑定
• 它产出的是诊断与补救 SQL，最终变更仍需人工确认后执行；高峰期终止长事务前，应先评估回滚代价