PostgreSQL MVCC看似简单，真正落地时却很容易踩坑。如果你正在使用 PostgreSQL，一定遇到过这种情况：明明只插入了 100 万行数据，表却占了几个 G 的磁盘空间；跑了几个小时的批量更新后，查询突然变慢。大概率是表膨胀（Table Bloat）来了。表膨胀不是 bug，而是 MVCC（多版本并发控制）设计哲学下的自然结果。很多教程一上来就讲参数调优，但如果不理解背后原理，调优就是碰运气。这篇文章会用最直白的方式讲清楚：MVCC 为什么会产生死元组？Autovacuum 怎么工作？以及我们怎么判断和调整它。
1. 先理解 PV：PostgreSQL 的 MVCC 到底干了什么
我的处理经验
MVCC 是 PostgreSQL 实现高并发的核心技术。简单说：当多个事务同时读写同一行时，每个事务看到的都是自己“快照”里的数据，互不干扰。但为了实现这种隔离，PostgreSQL 不会原地修改数据，而是每次 UPDATE 或 DELETE 时，在物理磁盘上“复制”出一份新的行版本（称为元组）。
举个例子：表里有一行 id=1, name=’Alice’。事务 A 执行 UPDATE 把 name 改成 ‘Bob’。PostgreSQL 不会直接擦掉 ‘Alice’，而是保留旧版本，并在旁边写一个新版本 ‘Bob’。旧版本就是“死元组”（dead tuple）。只有等到事务 A 提交之后，其他事务才能看到新版本；而旧版本则需要等所有可能还看到它的事务都结束，才能被清理。
DELETE 同理：删除一行只是标记它为“已删除”，真实数据还在磁盘上。INSERT 虽然不会产生死元组，但后续的 UPDATE/DELETE 会不断堆积死元组。这就是表膨胀的根源——死元组越积越多，表文件越来越大，而实际有效的数据只占一小部分。
2. 表膨胀带来的三个麻烦与PostgreSQL MVCC
配置前的检查
死元组堆积首先导致磁盘空间膨胀。假设你每天更新 10% 的数据，一周后表大小可能翻倍。其次，查询性能下降：PostgreSQL 需要扫描整个表（包括死元组）来找到有效数据，导致 I/O 暴涨，索引也变慢。更隐蔽的是，死元组会污染共享缓冲区，降低缓存命中率。一个 10 GB 的表如果膨胀到 30 GB，即使只查 1 GB 的有效数据，也可能触发磁盘读取。
最危险的是：当死元组超过一定比例时，PostgreSQL 的查询计划器可能误判，选择错误的执行计划，导致全表扫描。
3. 拯救者 Autovacuum——但它不是银弹
配置前的检查
Autovacuum 是 PostgreSQL 自带的后台守护进程，专门负责清理死元组并回收磁盘空间。它默认开启，但它的触发逻辑是“惰性的”：只有当表上死元组数量达到某个阈值（由 autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * 表行数 计算）时，才会启动。对于小型表没问题，但对于更新频繁的大表，这个阈值可能永远达不到，或者 Autovacuum 跑得没有更新快。
更糟糕的是，Autovacuum 清理时如果遇到长事务（运行超过一小时的事务），它无法移除该事务之后产生的死元组。这些死元组会一直保留，直到长事务结束。很多生产环境表膨胀的根源不是参数不对，而是存在未提交的长事务。
4. 怎么判断你的表已经膨胀了？
容易忽略的细节
不要等磁盘报警。用 PostgreSQL 自带的视图就能监控：
- pg_stat_user_tables：查看 n_dead_tup（死元组数），如果持续高位且 n_live_tup 增长缓慢，说明 Autovacuum 没跟上。
- pg_stat_all_tables：对比 last_autovacuum 时间，如果一个表很久没被 Autovacuum 处理，需要关注。
- pgstattuple 插件：可以精确计算表膨胀率（dead_tuple_percent）。通常超过 20% 就需要干预。
你还可以用系统查询：
SELECT schemaname, tablename, n_live_tup, n_dead_tup,
n_dead_tup::float / GREATEST(n_live_tup, 1) AS dead_ratio
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY dead_ratio DESC;这条语句会列出死元组占比最高的表。如果 dead_ratio 超过 0.2（20%），说明膨胀已经比较严重了。
补充参考：此处可内链到“PostgreSQL MVCC故障排查实例”。
5. 手动清理治标，Autovacuum 调优治本
遇到紧急膨胀，可以手动执行：
VACUUM ANALYZE your_table;加 VERBOSE 可以看到清理细节。但手动 VACUUM 不能回收磁盘空间给操作系统（只能给本表重用），想真正回收空间需要 VACUUM FULL（会锁表，生产慎用）。所以日常依赖 Autovacuum 才是正道。
5.1 调整触发阈值
默认的 scale_factor=0.2 意味着一个 1 亿行的表，要等死元组达到 2000 万行才触发清理。这太晚了。建议将大表的 autovacuum_vacuum_scale_factor 改为 0.01 甚至 0.005，同时调小 autovacuum_vacuum_threshold（比如 1000）。这样 Autovacuum 会更勤快。
但注意：太频繁的 Autovacuum 会增加 CPU 和 I/O 开销。需要平衡。
5.2 加速清理过程
Autovacuum 的速度由 autovacuum_max_workers（默认 3）和 autovacuum_vacuum_cost_limit（默认 200）控制。如果磁盘快被撑爆了，可以临时提高 cost_limit 到 1000，并减少 cost_delay（默认 20ms）到 2ms，让清理更快完成。但生产环境要逐个表设置，避免影响正常业务。
5.3 最容易被忽略的：长事务监控
修改参数之前，先排查长事务：
SELECT pid, now() - xact_start AS duration, state, query
FROM pg_stat_activity
WHERE state != 'idle'
AND xact_start IS NOT NULL
ORDER BY duration DESC;如果有超过几分钟的事务在跑，Autovacuum 死活也清不掉死元组。先杀掉或提交长事务，Autovacuum 才会生效。
延伸阅读：此处可内链到“PostgreSQL MVCC配置案例”相关文章。
相关阅读：此处可内链到“PostgreSQL MVCC常见问题”专题。
PostgreSQL MVCC：6. 不用恐慌：PostgreSQL 16 之后的一些改进
实际操作要点
PostgreSQL 13 引入了更好的 Autovacuum 调度（基于 WAL 使用率），16 又进一步优化了大表清理的锁冲突。如果你的 PostgreSQL 版本在 13 以上，默认参数已经比老版本好很多。但作为运维者，理解原理永远比盲目依赖默认值靠谱。
想继续深入：此处可内链到“PostgreSQL MVCC优化清单”文章。
7. 总结：从原理到实操的 checklist
先看关键判断
- 每周监控 pg_stat_user_tables 中 n_dead_tup 的变化趋势。
- 对大表单独设置 autovacuum_vacuum_scale_factor=0.01 或更小。
- 确保没有长事务在运行（定期查询 pg_stat_activity）。
- 如果膨胀已经发生，先做 VACUUM（非 FULL），然后考虑用 pg_repack 在线重建表（需安装插件）。
- 磁盘空间不够时，优先扩展磁盘或删除无关数据，不要直接在膨胀表上跑 VACUUM FULL。
表膨胀就像冰箱里的积霜，定期除霜才能保持制冷效率。Autovacuum 是自动除霜功能，但你还是需要偶尔检查一下霜层有多厚。希望这篇文章能帮你理解背后的原因，再遇到数据库突然变慢时，多一个排查方向。真正做好PostgreSQL MVCC，靠的不是参数堆砌，而是持续验证。
延伸阅读