PostgreSQL 表越来越大、数据库越来越慢：VACUUM 积压与 dead tuples 只读证据
下载经过PostgreSQL 14—18隔离验证的单行只读聚合卡，在不输出schema、表名、用户或SQL的前提下观察dead tuples、dead ratio和维护新鲜度。
先用统计聚合判断是否存在需要继续复核的VACUUM证据压力，再结合长事务、写入节奏、磁盘、冻结年龄和维护窗口；压力桶不是自动维护指令。
适用对象
- SQL-PG-09已在PostgreSQL 14.20、15.18、16.14、17.10和18.4隔离合成环境完成运行合同。
- 脚本只返回单行实例级聚合，不输出schema、表名、用户、SQL、PID、地址或业务对象。
- n_live_tup、n_dead_tup和n_mod_since_analyze是统计估算，不能直接证明精确膨胀空间或根因。
- 压力桶只决定是否继续核对，不授权自动VACUUM、ANALYZE、改参数、kill、切换或扩大权限。
dead tuples很多、autovacuum没跑，应该先看什么
先区分统计信号、对象级证据、根因和授权动作，避免把一条指标直接变成维护命令。
公开卡只回答实例层面的“是否存在需要继续复核的证据压力”。对象级表名、长事务、冻结年龄、表和索引空间、写入峰值及维护配置应在受控位置由负责人继续核对。
如果返回insufficient_visibility，应停止并由负责人判断最小权限；不要为了看对象身份自动扩大权限。
| 信号 | 可以帮助判断 | 不能单独证明 |
|---|---|---|
| dead rows与比例 | 旧版本估算是否值得继续复核 | 精确膨胀空间或autovacuum故障 |
| 长期未见vacuum | 维护新鲜度证据可能不足 | 应该立即手工VACUUM |
| 分析后修改量 | 统计信息可能需要继续核对 | 执行计划一定错误 |
| 压力桶 | 是否进入固定范围人工复核 | 维护动作、根因或效果承诺 |
从单行聚合到受控维护决定
先保存当前时间窗和业务现象，再运行只读卡。出现压力后补充对象级证据、长事务、磁盘、冻结年龄、写入和最近变更，最后由负责人决定观察、复核或单独批准维护。
VACUUM证据五步
- 01
01
固定现象
记录版本、时区、变慢或增长窗口、业务影响和近期变更。
- 02
02
运行只读卡
用受控可见性获取单行实例聚合，建议客户端5秒超时。
- 03
03
补对象证据
在受控位置核对具体表、长事务、冻结年龄、空间和写入节奏。
- 04
04
形成候选解释
同时保留计划、IO、缓存、复制和配置等反证。
- 05
05
单独授权
观察、维护、改参数或其他动作分别审批、回读和回滚。
公开卡不得自动VACUUM、ANALYZE、改参数、kill、切换、写入或扩大权限。
下载五版本隔离验证的只读SQL与脱敏样例
SQL和样例逐字节复用inchTraining权威文件。README记录字段含义、权限、5秒超时、统计估算和未验证边界；公开文件不包含客户或生产数据。
本节判断
- 验证版本：PostgreSQL 14.20、15.18、16.14、17.10、18.4。
- 合成压力：删除800/2,000行，最大dead ratio为25%，清理后归零。
- 未验证：生产、客户、托管云权限差异、精确膨胀空间、根因和维护效果。
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
n_dead_tup很高就应该立刻VACUUM FULL吗？
不应该只凭这个字段。它是估算值，还要核对对象大小、长事务、冻结年龄、磁盘、维护窗口、锁和回滚边界；VACUUM FULL会重写并锁表，必须单独评估和授权。
为什么脚本不输出表名？
公开卡用于安全分流，只回答实例层是否存在证据压力。对象身份、业务用途和完整统计应在受控位置按最小权限查看。
压力桶是low就说明没有问题吗？
不说明。它只反映采集时刻、当前可见范围内的聚合统计；执行计划、IO、缓存、锁、复制、对象级膨胀和历史窗口仍需其他证据。
这张卡能自动修复autovacuum吗？
不能。它不执行维护、改参数、写入或权限操作，只提供进入人工复核的首轮证据。