第 15 章：MVCC

zjc 于 2026-01-15 发布

这是《PostgreSQL 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 MVCC（Multi-Version Concurrency Control）让读不阻塞写、写不阻塞读，是 PostgreSQL 并发控制的核心。

每个行版本包含系统字段：

查看：

SELECT xmin, xmax, ctid, *
FROM users
WHERE id = 1;

UPDATE id=1
    |
    +-- old tuple: xmin=100, xmax=101
    +-- new tuple: xmin=101, xmax=0

事务 100 之前的快照看到旧版本；事务 101 之后提交后的快照看到新版本。

可见性取决于：

当旧版本对所有活跃快照不可见后，它成为死元组：

dead tuple
  -> VACUUM 标记空间可复用
  -> 后续插入或更新可复用

查看：

SELECT
    relname,
    n_live_tup,
    n_dead_tup,
    last_vacuum,
    last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

原因：

后果：

以下对象会保留旧版本：

检查复制槽：

SELECT slot_name, slot_type, active, restart_lsn
FROM pg_replication_slots;

检查两阶段事务：

SELECT * FROM pg_prepared_xacts;

VACUUM 不消除膨胀空间给操作系统，而是标记页内空间可复用。想缩减文件需要重建表或使用在线重建工具。

VACUUM users;
VACUUM FULL users;

VACUUM FULL 会重写表并请求 AccessExclusiveLock，生产慎用。

事务 ID 有限，需要冻结非常旧的事务。大量未冻结旧数据会触发激进 autovacuum，甚至阻止写入。

关注：

SELECT
    relname,
    n_dead_tup,
    autovacuum_count,
    last_autovacuum
FROM pg_stat_user_tables;

以及告警中的：

database is not accepting commands to avoid wraparound risk

必须提前治理长事务和 autovacuum。

MVCC 通过多版本实现高并发，代价是旧版本留在表中等待 VACUUM 清理。理解死元组、长事务、复制槽和表膨胀，是 PostgreSQL 生产运维的关键。