MVCC并发控制机制：从快照隔离到死元组
PostgreSQL的并发控制依赖MVCC（Multi-Version Concurrency Control），每个事务写入新版本时不会覆盖旧版本，而是在表中保留多个物理行（称为元组）。这种设计让读操作无需等待写锁，但代价是旧版本会持续堆积。
元组头与事务可见性判定
每个元组头部包含两个关键字段：xmin（创建该元组的事务ID）和xmax（删除/更新该元组的事务ID，若未删除则为0）。一个事务读取元组时，通过比较当前快照的事务ID列表与xmin/xmax，判断该元组是否可见。规则大致如下：
- 如果xmin对应的提交状态为已提交且不在当前事务的“未提交列表”中，则元组可见；
- 如果xmax非0且对应的提交状态为已提交或回滚，则元组可能不可见；
- 如果xmin与xmax属于当前事务，则根据事务自身的行为判断。
这套规则保证了“读已提交”和“可重复读”隔离级别下的一致性视图。但事务ID（32位，最大约42亿）存在回绕风险——事务ID环绕后，旧元组可能被误认为可见。PostgreSQL通过“冻结”（FREEZE）标记元组来应对，即设置事务ID为一个特殊的值（FrozenTransactionId），使其永远可见。
快照隔离与写冲突处理
在可重复读隔离级别下，事务获取快照时记录所有活跃事务ID，后续读操作只看该快照内的元组版本。当两个事务试图更新同一行时，后提交的事务会检测到冲突并抛出“无法序列化”错误——这并非死锁，而是MVCC的乐观策略。实际场景中，频繁的行更新会导致大量死元组残留。
死元组膨胀的根源与影响
每次UPDATE都会标记旧元组的xmax为当前事务ID（若事务提交则视为删除），同时插入新元组。DELETE同样标记xmax。这些被标记为删除但尚未被VACUUM清理的元组就是“死元组”。
存储放大：一行的多个副本
假设一张表有1亿行活跃数据，每秒执行1000次UPDATE。如果VACUUM频率不足，一天可能积压数千万死元组。结果表文件膨胀到实际活跃数据的2~3倍，不仅浪费磁盘空间，还导致全表扫描需要读取更多页面——即使使用索引，死元组也会占用B+树的叶子节点空间。
事务ID回绕的加速器
元组越积越多，事务ID消耗速度加快。当pg_database.datfrozenxid与当前事务ID的差值接近2^31时，PostgreSQL会强制进入“紧急清理模式”，此时所有事务（包括只读查询）都会阻塞。这是最具破坏性的后果之一。
VACUUM深度调优：参数、监控与策略
VACUUM的核心任务是回收死元组占用的空间、更新可见性映射（VM）并冻结旧事务ID。调优方向从自动触发阈值、代价模型、冻结策略三个维度展开。
自动VACUUM触发阈值
PostgreSQL通过两个参数控制自动VACUUM何时启动：
- autovacuum_vacuum_threshold（默认50）：表中死元组数超过此值才可能触发。
- autovacuum_vacuum_scale_factor（默认0.2）：死元组比例超过“阈值 + 表行数×因子”时触发。
对于大表（如10亿行），scale_factor=0.2意味着死元组达到2亿行才VACUUM，间隔过长。建议缩小scale_factor至0.01~0.05，或用更稳定的autovacuum_vacuum_insert_threshold（PG13+）来控制插入频繁表的清理。
代价模型限制I/O突增
VACUUM从buffer pool读取脏页并写出清理后的页面，若不加限制可能导致I/O飙升。代价模型参数：
- vacuum_cost_page_hit（默认1）：页在共享缓存中命中时积累的代价。
- vacuum_cost_page_miss（默认10）：需从磁盘读取。
- vacuum_cost_page_dirty（默认20）：需写出脏页。
- vacuum_cost_limit（默认200）和vacuum_cost_delay（默认0ms）：当累积代价达到limit后，进程休眠delay毫秒。
如果系统I/O资源紧张，可将vacuum_cost_limit降至100~150，并设置vacuum_cost_delay=2~5ms，让VACUUM柔和地完成。反之，若希望快速清理，可关闭代价延迟（cost_delay=0）并提高limit。
监控VACUUM进度
PG 9.6+提供了pg_stat_progress_vacuum视图，可以实时查询正在运行的VACUUM进度：
SELECT * FROM pg_stat_progress_vacuum;关键字段包括phase（当前阶段：scanning heap、vacuuming indexes、cleaning up等）、heap_blks_total、heap_blks_scanned。通过监控可以判断VACUUM是否因死锁或长事务停滞。
手动VACUUM与冻结维护
对于老旧的数据库，手动执行VACUUM (FREEZE) table_name可以强制将指定表的所有可冻结元组标记为冻结，避免回绕风险。注意大表上的FREEZE会锁表并产生大量WAL，最好在维护窗口执行。也可使用vacuumdb --freeze --jobs=4并行冻结。
避免VACUUM失败：长事务与复制槽
如果存在持久的“空闲事务”（例如pg_stat_activity中state=’idle in transaction’且backend_xmin很久不更新），VACUUM无法回收那些比该事务开始时间还早的死元组。监控pg_stat_activity中的backend_xmin和backend_xid，若长期不变化应终止空闲事务。同样，逻辑复制槽（logical slot）会保留WAL和死元组，需及时确认消费。
调优案例：高并发更新表
一张订单表（约5000万行），每秒约500次UPDATE状态。初期使用默认参数，每天表膨胀约15%，全表扫描从1.2秒升到5秒。调整如下：
- 将该表的autovacuum_vacuum_scale_factor改为0.02，threshold维持50，死元组达到100万行即开始清理。
- 在业务低峰期手动执行
VACUUM (VERBOSE, ANALYZE) orders，触发FULL清理前先观察碎片率。 - 调整vacuum_cost_delay=2ms，vacuum_cost_limit=150，避免VACUUM高峰与业务冲突。
- 启用
autovacuum_vacuum_insert_threshold（PG13+）控制插入膨胀。
一周后表大小稳定在原始活跃数据的1.3倍左右，查询响应恢复正常。
总结关键实践
- 避免默认参数：大表必须降低scale_factor，小表可以忽略。
- 监控死元组比例：用
SELECT n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname='...';。 - 冻结规划：定期对近一年内频繁更新的表执行VACUUM FREEZE，或设置long_running_tx监控。
- 善用并行VACUUM：PG13+支持
PARALLEL选项（如VACUUM (PARALLEL 2) table_name），利用多核加速索引清理。
MVCC让PostgreSQL在读写并发中保持一致性，而VACUUM则是维持系统长期稳定的必需品。理解它们的互动机制，才能做出有效的调优决策。
延伸阅读