痛点
线上 PostgreSQL 运行半年后，DBA 发现一张 2000 万行的订单表实际占用磁盘 45GB，而有效数据只有 12GB——表膨胀率超过 250%。更棘手的是，pg_stat_activity 中频繁出现 WARNING: database "order_db" must be vacuumed within 10000000 transactions 告警，意味着事务 ID（XID）回卷风险正在逼近。
这是 PostgreSQL MVCC 机制的"副作用"：每次 UPDATE/DELETE 不会立即回收旧版本行（dead tuple），而是依赖 VACUUM 进程清理。一旦 autovacuum 跟不上写入速度，或者存在长事务阻塞清理，表膨胀和 XID 回卷就会成为定时炸弹。
方案
核心思路：调优 autovacuum 参数 + 消除长事务阻塞 + 建立监控告警，三管齐下根治问题。
实操步骤
第 1 步：诊断当前膨胀状态
先摸清哪些表膨胀最严重，以及 autovacuum 的执行情况：
-- 查看 dead tuple 最多的 Top 10 表
SELECT schemaname, relname,
n_dead_tup,
n_live_tup,
round(n_dead_tup * 100.0 / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
last_autovacuum,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;
-- 查看当前最老的事务 XID 与回卷距离
SELECT datname,
age(datfrozenxid) AS xid_age,
2147483647 - age(datfrozenxid) AS remaining_xids
FROM pg_database
ORDER BY xid_age DESC;
如果 dead_pct 超过 20% 或 xid_age 超过 5 亿，就需要立即干预。
第 2 步：针对高写入表定制 autovacuum 参数
默认 autovacuum 配置对高写入表往往不够激进。针对问题表单独调参：
-- 对高写入表降低触发阈值、提高清理速度
ALTER TABLE orders SET (
autovacuum_vacuum_threshold = 1000, -- 默认 50，降低触发门槛
autovacuum_vacuum_scale_factor = 0.01, -- 默认 0.2，改为 1% 即触发
autovacuum_vacuum_cost_delay = 2, -- 默认 2ms（PG14+），加速清理
autovacuum_vacuum_cost_limit = 1000, -- 默认 200，允许更大 IO 预算
autovacuum_freeze_max_age = 300000000 -- 3 亿，提前冻结防回卷
);
同时在 postgresql.conf 全局层面优化：
# 增加 autovacuum worker 数量（默认 3，高写入场景建议 5-6）
autovacuum_max_workers = 5
# 全局降低 cost_delay 加速清理（PG14+ 默认 2ms，老版本默认 20ms）
autovacuum_vacuum_cost_delay = 2ms
# maintenance_work_mem 直接影响 VACUUM 效率
maintenance_work_mem = 1GB
# 提前触发 aggressive vacuum 防止 XID 回卷
vacuum_freeze_min_age = 5000000
vacuum_freeze_table_age = 150000000
修改后 reload 配置：
# 无需重启，reload 即可生效
sudo -u postgres pg_ctl reload -D /var/lib/postgresql/16/main
# 或
SELECT pg_reload_conf();
第 3 步：消除长事务阻塞并建立监控
长事务是 VACUUM 的天敌——只要有一个事务不结束，比它晚的 dead tuple 都无法回收。
-- 查找运行超过 1 小时的长事务
SELECT pid, now() - xact_start AS duration,
state, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
AND now() - xact_start > interval '1 hour'
ORDER BY duration DESC;
-- 必要时终止阻塞事务（先 cancel，不行再 terminate）
SELECT pg_cancel_backend(<pid>);
SELECT pg_terminate_backend(<pid>);
配置 idle_in_transaction_session_timeout 自动杀死空闲事务：
-- 全局设置：空闲事务超过 10 分钟自动终止
ALTER SYSTEM SET idle_in_transaction_session_timeout = '10min';
SELECT pg_reload_conf();
用 Prometheus + postgres_exporter 建立关键监控指标：
# prometheus-postgres-alerts.yml
groups:
- name: postgresql_vacuum
rules:
- alert: HighDeadTupleRatio
expr: pg_stat_user_tables_n_dead_tup / (pg_stat_user_tables_n_live_tup + pg_stat_user_tables_n_dead_tup) > 0.2
for: 30m
labels:
severity: warning
annotations:
summary: "表 {{ $labels.relname }} dead tuple 占比超过 20%"
- alert: XIDWraparoundRisk
expr: pg_database_datfrozenxid_age > 500000000
for: 5m
labels:
severity: critical
annotations:
summary: "数据库 {{ $labels.datname }} XID 年龄超过 5 亿，回卷风险"
避坑指南
坑 1：在业务高峰期手动执行 VACUUM FULL
VACUUM FULL 会对表加排它锁（AccessExclusiveLock），阻塞所有读写。生产环境应使用 pg_repack 在线重建：
# pg_repack 在线回收空间，不阻塞业务
pg_repack -d order_db -t orders --no-superuser-check
坑 2：调大 autovacuum_cost_limit 导致 IO 打满
cost_limit 设太大会在 VACUUM 期间消耗大量磁盘 IO，影响正常查询。建议先在低峰期用 pg_stat_progress_vacuum 观察清理速度：
SELECT relid::regclass, phase,
heap_blks_total, heap_blks_scanned, heap_blks_vacuumed
FROM pg_stat_progress_vacuum;
根据 IO 余量逐步调整，而非一步到位。
坑 3：忽略 replication slot 导致 VACUUM 无法推进
未消费的逻辑复制 slot 会阻止 VACUUM 冻结旧元组。定期检查：
SELECT slot_name, slot_type, active,
age(xmin) AS slot_xid_age,
age(catalog_xmin) AS catalog_xid_age
FROM pg_replication_slots;
对不再使用的 slot 及时清理：SELECT pg_drop_replication_slot('unused_slot');
总结
PostgreSQL 表膨胀和 XID 回卷是生产环境最常见的"慢性病"，核心应对策略：
- 诊断先行：用
pg_stat_user_tables和pg_database.datfrozenxid定位问题表和回卷风险 - 分表调参：对高写入表单独设置激进的 autovacuum 参数，全局增加 worker 数量
- 消除阻塞：设置
idle_in_transaction_session_timeout，监控长事务和 replication slot - 监控兜底：Prometheus 告警覆盖 dead tuple 比例和 XID 年龄两个核心指标
记住：VACUUM 不是"自动就够了"，高写入场景必须主动调优。定期巡检 + 告警驱动，才能让 PostgreSQL 在生产环境稳定运行。