PG 膨胀诊断

磁盘报警了，一张几百万行的表占了十几个 GB，跑完 VACUUM 空间一点没少——这不是 bug，是 PostgreSQL 的 MVCC 膨胀。

膨胀从哪来？

PostgreSQL 的 MVCC 机制决定了：每次 UPDATE/DELETE 都会留下死元组。VACUUM 只标记空间可重用，不把空间还给操作系统。日积月累，磁盘占用远超实际数据量。

传统排查的痛点

• pg_stat_user_tables 只有行数，没有真实膨胀量
• 挨个库 \dt+ 看大小，全靠人眼判断
• 分不清哪些膨胀值得处理，哪些是正常范围
• 没有统一的建议标准，新手不知该 VACUUM FULL 还是 REINDEX

pg-find-bloat 能做什么

连接一个 PostgreSQL 实例，自动遍历所有数据库，对每张表和每个索引做膨胀诊断：

输出示例

对每个数据库生成 Markdown 报告，含对象名、实际大小、膨胀量、比例、危害等级和建议动作。同时附带根因分析——是 autovacuum 参数过松？长事务阻塞？还是复制槽未消费？

使用方式

# 连接实例，全库自动巡检
# 只需提供连接串，只读诊断，不修改任何数据

适用人群

• 被 PostgreSQL 磁盘告警追着跑的中级 DBA
• 刚接手一个"历史遗留"PG 实例的运维人员
• 云 RDS 用户（无 superuser 自动降级估算模式）

项目已开源，欢迎试用和反馈。