PostgreSQL MVCC多版本并发控制原理

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

MVCC核心思想

还是回到那块办公室白板。传统数据库用“锁”来保护数据：一个人改的时候，其他人要么等着，要么干脆看不到。这就像白板前站着个保安——谁要写字，就得先排队，大家的时间都被浪费了。MVCC 把规则改成：别擦了，往上贴便签。每个“写者”都只需要在属于自己的那张新便签上写，旧便签留给旧读者，新便签服务新读者，互不干扰。

这个“一次更新生成新版本”的设计，就是多版本存储（Multi-Version Storage）。每一行逻辑数据，在物理上可能躺着好几个版本，通过版本链串起来。所谓快照隔离，是指每个事务在开始时取一个快照，它看到的世界就像按下快门的一瞬间，之后别人怎么贴便签都与它无关。

在 PostgreSQL 里，一行被 UPDATE 后，旧版本不会立刻消失，而是以“死元组（dead tuple）”的名义留在页面里，新版本通过 t_ctid 指向构成链条。不同版本允许同时存在的好处是：读操作永远不需要等写操作释放锁，写操作也只需要锁住“行”这一个点。付出的代价是：旧版本需要 VACUUM 回收，否则表会越来越大。

整个核心思想就是一句话：白板不是用来擦的，而是用来叠的。读旧、写新，各看各的版本，这就是 MVCC 的底层哲学。

事务机制基础

为了判断哪张便签“跟我有关”，每个进办公室的人要领一个工牌号——在 PG 里对应事务 ID（xid）。事务 ID 单调递增：谁来得早，谁的号就小。办公室前台（事务管理器）维护三样东西：当前未离场的人员清单、已走人员清单、被开除人员的清单，这正是“事务状态”的日常版本。

每个事务最终落在三种状态之一：进行中（in progress）、已提交（committed）、已回滚（aborted）。PostgreSQL 不会在每条元组里写死状态，而是把状态集中记在同一份“签到本”——CLOG（提交日志）里。判断“这个 xid 提交了吗”就是查 CLOG。

做可见性判断前，事务要先拍快照。快照由三部分构成：xmin（下界，小于它的都已结束）、xmax（上界，大于等于它的都是看不见的）、xip_list（活动事务清单，落在 xmin 与 xmax 之间的“还没走的人”）。在“读已提交”级别下，每一条 SQL 都会重新拍；在“可重复读”级别下，整个事务只拍一次。

前台手中的三份名单，决定了你能看到哪些便签。快照的“眼界”由此划定，接下来的一切判断都以它为基准。

行版本字段

每张便签打印出来时，都会盖两枚章：左边一枚“出生章”，盖着写者工号（xmin）；右边一枚“作废章”，等着盖删除者的工号（xmax）。便签刚贴上去时作废章是空的；一旦有人把它替换掉，就在上面盖下那个人的工号。裁判只看这两枚章，就能判断“这张便签你该不该看”。

在 PG 中，每个元组分为两部分：元组头（Header）和数据区（Data）。元组头里就藏着 xmin、xmax、t_ctid、infomask 等信息。infomask 是位掩码，记录一些“结论缓存”，例如“这个 xmin 已验证为已提交”，下次不必再查 CLOG，直接看标记，这就是 Hint Bits 的加速原理。

xmin 负责回答“谁生的我”；xmax 负责回答“谁杀了我”；t_ctid 负责把新旧版本串成链；infomask 负责把重复劳动的结果记下来。旧版本数据本身仍留在堆表里，直到 VACUUM 来清。

有了这两枚章，每张便签都自带着完整的身世：什么时候生的、被谁杀的。读者眨一下眼睛，就能从一堆便签中认出属于自己的那张。

可见性判断

现在一名员工看白板上的某一“行”时，发现上面叠了三四张便签。他该信谁？裁判的规则非常机械：自上而下翻，找到第一张“出生章在我熟悉范围内、且作废章没有生效”的便签，那就是他该看的内容。

形式化地说，一个元组版本 t 对快照 S 可见，需要同时满足两个条件：第一，xmin 在快照 S 之前的已提交集合里（出生已兑现）；第二，xmax 要么为 0（没人杀它），要么其所属事务在快照 S 时还没有提交（死亡未兑现，即删除者未生效）。

只要 xmin 未提交或已回滚，版本直接不可见；只要 xmax 所属事务已提交，版本就“已死亡”。剩余的边缘情形——xmax 事务仍在进行、或已回滚——都按可见处理。为了避免每次判断都查 CLOG，PG 顺手把结果写进 infomask（Hint Bits），第一次判完，后面都是 O(1) 的读标记。

（其中 $C_S$ 表示快照 S 形成时已提交的事务集合）

裁判不关心便签上的字写得对不对，只认两枚章。这机械的规则保证了任何时刻、任何事务看到的世界，都在逻辑上一致自洽。

事务隔离级别

快照就是员工戴的眼镜。四种隔离级别，本质上是“快门”按下的时机不同：有的人进门按一次快门，全场用一张照片；有的人每看一句话就重新拍一张。快门按得越频繁，越能看到“最新鲜”的画面，但也越可能看到前后不一致的画面。

PostgreSQL 支持四种隔离级别：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、可串行化（Serializable）。有意思的是，PG 中读未提交实际上表现与读已提交相同——因为 MVCC 天生不会脏读，想读未提交都读不到。

读已提交在每个语句开始前拍快照，因此同一事务内两次 SELECT 可能看到不同结果（不可重复读）。可重复读则在事务开始时拍一次，之后所有语句沿用同一快照。PG 的可重复读还能彻底避免幻读，代价是检测到写冲突时直接抛序列化错误。可串行化在可重复读之上叠加 SSI（串行化快照隔离），进一步保证事务可以等价于“串行”执行。

眼镜不影响你的视力，只影响快门。选哪种隔离级别，本质上就是在“新鲜度”与“一致性”之间做权衡。

更新删除流程

更新一块白板上的内容，内部发生了什么？员工掏出新便签写下最新值，啪地贴上去，然后在旧便签上盖一个自己的作废章。删除则更简单：找到当前可见的便签，直接盖作废章，不贴新的。

UPDATE：先定位目标行，加行锁，生成新版本（xmin=当前事务），并把旧版本 xmax 指向当前事务。DELETE：加行锁，把旧版本 xmax 指向当前事务，不产生新版本。行锁的用意是防止两个事务同时改同一行——MVCC 只解决读写互斥，写写依然要排队。

频繁 UPDATE 会让元组链变长，每次可见性判断都要沿链回看。HOT（Heap-Only Tuple）技术登场：如果更新的列不是索引列，就在原页面内追加新版本，不新增索引项，让索引始终指向链头，大幅降低索引维护成本。链太长或跨页更新时，HOT 会退化为普通更新。

更新就是“贴新签+盖旧章”两步连招，删除则是孤零零的一枚作废章。行锁只是便签板前的短暂排队，挡住的是两个写者，而不是读者。

VACUUM清理

白板上贴的便签越来越多，总得有人收拾。VACUUM 就是每晚来办公室的保洁阿姨：她把所有“已经不可能被任何事务看见”的旧便签撕下来，把位置腾出来给新便签用。但要注意：她只负责撕和腾，不负责把垃圾桶倒到楼下——空间是否归还操作系统是另一回事。

一个元组成为死元组（dead tuple）的充分条件是：它的版本已被更新或删除，且删除它的事务已提交，同时没有任何活跃事务的快照还能看到它。VACUUM 遍历表页，去掉这些死元组，更新可见性映射、维护统计信息。PG 提供 autovacuum 在后台自动执行这一过程。

事务 ID 是 32 位有符号整数，终究会用完。xid 回卷（wraparound）是 PG 最危险的场景之一：一旦用尽，数据库会强制停摆保护。解决办法是冻结（freeze）：把足够老的元组 xmin 标记为 Frozen，使其对所有事务都可见，从而避免参与 xid 比较。autovacuum 的一项重要职责就是赶在回卷之前把旧事务 ID 冻结。

保洁阿姨不是天天来，而是按“垃圾量”动态上门。调低阈值等于让阿姨来得更勤、但更打扰；调高则省资源、但表更容易胖。

MVCC实践优化

便签制度再好，如果大家贴完就走、保洁跟不上，办公室迟早变成废纸堆。实践中的 MVCC 优化，就是一套“卫生管理制度”：监控垃圾量、约束长驻者、定期大扫除。

表膨胀（bloat）指的是表实际占用空间远大于逻辑数据量。死元组若长期得不到回收、或 VACUUM 只腾出页内碎片却无法压缩页面，表就会越来越胖。最彻底的解决方案是 VACUUM FULL——表重写，把活元组复制进新文件，但会长时间锁表。

治理表膨胀的关键指标包括：n_dead_tup（死元组数）、last_vacuum、last_autovacuum，以及 pg_stat_user_tables 视图。常见的组合拳包括：合理设置 autovacuum 阈值与并发度；把大表按访问模式分区；坚决打击超长事务——长事务会让旧版本永远“有人看得见”，保洁阿姨永远没法动手。必要时在业务低峰期用 pg_repack 在线重写表，替代会锁表的 VACUUM FULL。

好的办公室，靠的是每一位员工及时贴签、保洁阿姨按量到岗、“长驻会议”及时散场。MVCC 的优化没有银弹，唯有读懂快照与版本，才能在高并发的钢丝上走得稳。

AI 应用场景

Python 演示

class Tx:    def __init__(self, tid):        self.tid = tid        self.state = 'active'     def commit(self):        self.state = 'committed'     def abort(self):        self.state = 'aborted'  class Tuple:    def __init__(self, xmin, xmax=0):        self.xmin = xmin        self.xmax = xmax        self.chain = [self]     def new_version(self, tid):        self.xmax = tid        new_t = Tuple(tid)        self.chain.append(new_t)        return new_t  class MVCCStore:    def __init__(self):        self.rows = {}        self.txs = {}     def new_tx(self):        tid = len(self.txs) + 1        self.txs[tid] = Tx(tid)        return tid     def commit(self, tid):        self.txs[tid].commit()     def abort(self, tid):        self.txs[tid].abort()     def visible(self, t):        if self.txs[t.xmin].state != 'committed':            return False        if t.xmax != 0 and self.txs[t.xmax].state == 'committed':            return False        return True     def read(self, key):        for v in reversed(self.rows[key].chain):            if self.visible(v):                return v        return None  def main():    store = MVCCStore()    t1 = store.new_tx()    store.rows['room_a'] = Tuple(xmin=t1)    store.commit(t1)     t2 = store.new_tx()    store.rows['room_a'].new_version(t2)     print('t2 未提交时读取:', store.read('room_a').xmin)    store.commit(t2)     print('t2 提交后读取:', store.read('room_a').xmin)  main()

1. self.xmax = tid给旧版本盖上“死亡戳”，表示被当前事务替换，对应 UPDATE 的双章操作。
2. def visible(self, t):裁判函数，逐条复刻“出生戳已提交且死亡戳未生效”的核心可见性规则。
3. if self.txs[t.xmin].state != 'committed':出生戳未提交则不可见，等价于“便签的出生章无效”。
4. if t.xmax != 0 and self.txs[t.xmax].state == 'committed':死亡戳已提交则不可见，等价于“作废章已盖实”。
5. for v in reversed(self.rows[key].chain):从最新版本往回找第一个可见版本，模拟版本链的回溯查找。
6. store.commit(t2)事务提交后，新版本才对后续读者可见，旧版本彻底变为死元组。

常见误区

面试题