MVCC 与事务

第 1 章把物理地基铺到了 xmin/xmax 这两个隐藏列就停手了：它只说「这一版谁造、谁废」是记录在那里的，没说这条记录怎么被读。本章补上的就是「读」这一侧——一个事务执行查询时，靠一把叫快照（snapshot）的尺子，把堆里同一行的多个版本筛成「此刻该被这个事务看见的那一个」。整个 MVCC（多版本并发控制）就是这把尺子加一条判定规则，别无其他。理解了它，死元组为什么产生、膨胀为什么失控、HOT 为什么省事，全是直接推论。

§1快照：判断「谁已定论」的依据

快照是拍照那一刻的一张事务清单：哪些 xid 已经定论、哪些还在进行、哪些尚未开始。

PG 给每个事务分配一个单调递增的事务 ID——xid（也写作 txid）。先有的事务 xid 小，后开的 xid 大。一个快照本质上由三部分构成，记作 (xmin, xmax, xip[])，注意这里的 xmin/xmax 是快照的字段，与 tuple 上同名的隐藏列不是一回事：

• xmin（快照下界）：所有小于它的 xid 都已经定论——要么早已提交、要么早已中止，不再有悬念。它是「已盖棺论定」的水位线。
• xmax（快照上界）：拍快照那一刻，xid 计数器分配到的下一个值。所有大于等于它的 xid 在拍照时还没开始，对本快照一律不可见。
• xip[]（in-progress 列表）：落在 [xmin, xmax) 区间内、但拍照那一刻仍在进行（既未提交也未中止）的事务 xid 列表。这是快照里唯一需要逐个列举的部分。

把三者合起来读一个 xid 的状态就一目了然：小于 xmin → 已定论；大于等于 xmax → 尚未开始；落在区间内且在 xip[] 里 → 拍照时还在飞；落在区间内但不在 xip[] 里 → 拍照前已提交。这四种状态覆盖了所有 xid，没有第五种。

底层机制（比文档深一层）。 快照的 xip[] 解释了一个常被忽略的事实：一个事务提交得早不等于它对你可见得早。设想事务 198 在事务 200 之后才提交，而你的快照在 199 时刻拍下。即便 198 的 xid 比 200 小，只要拍照那一刻 198 还在进行，它就被收进 xip[]，于是它写的版本对你不可见——可见性看的不是 xid 的大小，而是「拍照时是否已提交」。这也是为什么快照必须显式带一个 xip[] 列表，而不能简单地用一个「提交水位线」一刀切：事务的提交顺序与开始顺序可以不一致，区间内的「空洞」必须逐个记下来。这一点在 §2 的可见性判定里会被直接用到。

§2可见性：一道纯比对题

一个版本对快照是否可见，由它的 xmin/xmax 跟快照比对决定——不加锁、不等待。

判定规则可以浓缩成一句话。一个 tuple 对某快照可见，当且仅当下面两个条件同时成立：

• 它的创建者已提交、且在快照看来已完成——即 tuple 的 xmin 对应的事务已提交，且该 xid 小于快照上界、不在快照的 xip[] 里。换言之，造出这一版的事务，在拍照那一刻已经盖棺论定为「提交」。
• 它的废止者尚未生效——即 tuple 的 xmax 要么为 0（没人删它），要么对应一个未提交、已中止或拍照时仍在进行的事务（在快照看来还没真正废掉它）。

反过来，只要创建者在快照看来还没提交，这一版就不可见（还没生效）；只要废止者在快照看来已经提交，这一版也不可见（已被废）。两个条件，四种组合，结论唯一。

底层机制（比文档深一层）。 这道纯比对题正是「读不阻塞写、写不阻塞读」的全部原因，值得拆开看清两个方向。

读为什么不阻塞写。一次 SELECT 要做的，只是拿快照去逐个比对候选 tuple 的 xmin/xmax，挑出可见的那一版返回。整个过程不申请任何行锁、不关心此刻有没有别的事务正在改这一行——因为它要的版本已经物理存在于堆里，比对完即可读走。与此同时另一个事务尽可以去写新版本，那只是往堆里追加一份 v3，丝毫不影响正在比对 v1/v2 的读者。读者从不等锁，于是读不阻塞写。

写为什么不阻塞读。一次 UPDATE 不去触碰旧版本的数据字节（只给旧版本盖一个 xmax 失效戳、并在别处追加新版本），旧版本因此完整保留。任何持有「能看到旧版本」的快照的读者，照样能读到那份未被销毁的旧数据，无须等写者结束。两个方向合起来，就是 MVCC 用「多版本物理共存 + 快照比对」换掉了「读写互斥锁」——代价是堆里堆积的旧版本（§4 的死元组）。这条因果链是第 1 章「为省并发开销、把清理后移给 VACUUM」那句话的正面兑现。

§3隔离级别：差别只在「何时拍快照」

四个隔离级别在 PG 里的真正差异，归结为快照在什么时机被拍下、被沿用多久。

PG 支持 SQL 标准的四个隔离级别，但实现上有自己的取舍：

• Read Uncommitted：标准里允许脏读（读到未提交数据）。PG 没有脏读的实现路径——它把这一级直接等同于 Read Committed。声明 Read Uncommitted 不会让你读到任何未提交的版本。
• Read Committed（默认）：每一条语句开始时取一张新快照。于是每条语句都能看到「该语句开始那一刻」已提交的所有数据。这是 PG 的默认级别。
• Repeatable Read：事务的第一条语句取一张快照，整个事务自始至终沿用它。事务内任何查询都基于同一张快照，看到的是「事务开始那一刻」的数据视图——这就是快照隔离。
• Serializable：在 Repeatable Read 的快照隔离之上，叠加 SSI（Serializable Snapshot Isolation，可序列化快照隔离）+ 谓词锁，监控事务之间的读写依赖，一旦发现会破坏可序列化的危险模式就让其中一个事务失败。

底层机制（比文档深一层）。 表里两个值得停下来想的格子。

其一，Read Committed 为什么会「不可重复读」。因为它每条语句重新拍快照。同一个事务里连续两条相同的 SELECT，第一条用快照甲、第二条用快照乙；若两条之间别的事务提交了改动，乙就量得到、甲量不到，两次结果于是不同。这不是 bug，而是「每语句新快照」的直接后果——要消除它，把隔离级别提到 Repeatable Read，让整事务共用一张快照即可。

其二，也是与 MySQL 分道扬镳的一刀：PG 的 Repeatable Read 遇到写冲突会抛错，而不是阻塞。当两个 Repeatable Read 事务试图更新同一行，后提交的那个不会默默覆盖、也不会卡住等锁，而是直接报 40001（serialization_failure，序列化失败），把事务回滚——应用必须捕获它并重试整个事务。这与 InnoDB 的 Repeatable Read「后者阻塞等锁、拿到后基于旧读继续」是根本不同的并发哲学：PG 让快照保持纯粹（事务视图绝不被中途的写污染），代价是把冲突显式抛给应用处理。这条对比是第 6 章的主线之一，详见 第 6 章 · 默认隔离级别与冲突处理。

§4死元组：没有任何快照能看到的旧版本

当一个旧版本的 xmax 已提交、且对所有现存快照都不可见，它就成了死元组——纯垃圾，等回收。

一个 tuple 版本成为死元组（dead tuple）的条件是两点合一：它的 xmax 对应的事务已经提交（即它确实被某个已生效的事务删除或更新取代了），并且当前数据库里没有任何活动快照的视图能再看到它（所有比它的 xmax 更老的、本来还会需要它的事务都已经结束）。满足这两点，这一版对全世界都不可见，永远不会再被任何查询返回——它就是确定的垃圾。

但死元组不会自动消失。它仍然物理地占着所在 Page 的一个槽位和数据空间；如果它对应的行在被索引的列上有值，每个相关索引里也还留着一条指向它的索引项。这些空间和索引项要等 VACUUM 来回收——这是第 3 章的主题（详见 第 3 章 · VACUUM）。在 VACUUM 跑到之前，死元组就是表和索引里实打实的「虚胖」。

§5HOT：不动索引的更新

新版本落在同一个 Page、且没改任何被索引的列时，更新不产生任何新索引项。

HOT 更新触发需要两个条件同时满足：

• 被改的列上没有索引——这次 UPDATE 修改的所有列，都不是任何索引的组成列。若改了哪怕一个被索引的列，索引就必须指向新值，HOT 失效。
• 新版本能放进同一个 Page——旧版本所在的那个 8KB Page 还有足够空闲（这正是第 1 章 fillfactor 预留空间的用途）装下新版本。若同页放不下、新版本只能落到别的 Page，HOT 也失效。

两个条件都满足时，HOT 这样工作：新版本写进同一个 Page；旧版本的 tuple 头被标记上 HEAP_HOT_UPDATED，其 ctid 指向同页内新版本的槽位，于是同一行的版本在页内串成一条 HOT 链；最关键的是——不为新版本插入任何索引项，所有索引仍然指向旧版本的那个 line pointer 槽。查询走索引命中旧 line pointer 后，顺着 HOT 链往下走，找到当前可见的新版本返回。索引「以为」自己还指着原来那行，实际由堆内的链接把它接到了最新版本。

底层机制（比文档深一层）。 HOT 的红利和它的脆弱性是同一枚硬币的两面，必须一起记。

红利一侧：HOT 把「更新即更新所有索引」这条默认开销，在常见的「只改非索引字段」场景里归零。同时它还顺手缓解膨胀——HOT 链上被淘汰的中间版本，可以由一种轻量的页内清理（heap-only 的剪枝）在普通访问路径上就地回收槽位，不必等完整 VACUUM。对一张「主键 + 几个索引列基本不动、只频繁更新某个非索引计数/状态字段」的表，HOT 是决定其写入吞吐的关键机制。

脆弱性一侧，也是最实用的陷阱：给一个频繁更新的列加上索引，会让该列的更新从此无法走 HOT。因为「被改的列上没有索引」这条触发条件被破坏了——每次更新都退回「写新堆版本 + 给这个新索引插新项」的路径，写入开销陡增，且这个新索引本身也会因不断追加的索引项而快速膨胀。一个看似无害的「为了查询加个索引」，在高频更新列上会同时招来写放大与索引膨胀两笔账。这条权衡是第 4 章索引设计的核心之一，详见 第 4 章 · 索引与 HOT 的相互作用。

§6膨胀：死元组积累快于回收

死元组和失效索引项的积累速度超过 VACUUM 的回收速度，表与索引就持续虚胖。

膨胀指表（以及其索引）里死元组与失效索引项不断积累、占用的空间远超实际存活数据，且回收跟不上产生。适度的死元组是 MVCC 的正常代谢，VACUUM 会把空间标记为可复用；但当产生持续快于回收，体积就单向上涨——缓存里能装的有效行变少、顺序扫描要读更多无用 Page、查询变慢。

最致命的失败模式，是长事务 / idle-in-transaction（事务里执行完语句却迟迟不提交、一直挂着）持有一张老快照。回顾 §4：一个旧版本要升级成可回收的死元组，前提是「再没有任何活动快照能看到它」。只要有一个老事务的快照还活着，那个老快照能看到的所有旧版本就都不能被判定为死元组——VACUUM 即便跑，也不敢回收它们。PG 用一条回收水平线（xmin horizon）来记录「当前最老的、仍被某个活动事务需要的 xid」；一个长事务把这条水平线死死钉在它开始的那个 xid 上，使其无法前进。

底层机制（比文档深一层）。 这个失败模式最反直觉、也最致命的一点：膨胀的范围远超那个长事务实际碰过的数据。回收水平线是数据库全局的单一水位，不是「这个事务读了哪些表」的精细记录。VACUUM 在回收任何一张表时，都要拿这条全局水平线做安全判定：凡 xmax 比水平线新的死元组，一律不敢回收（因为理论上那个老事务还会去读这张表）。于是一个挂在那里、只查过一张小表的 idle-in-transaction 事务，会让全库所有表上、在它开始之后产生的死元组统统无法回收——哪怕那些表它从未访问。一张高频更新的核心表，会在几小时内因为另一个连接上一个被遗忘的未提交事务而膨胀到原来的数倍。这就是为什么生产库要监控并杀掉长时间 idle-in-transaction 的连接，也是为什么「拿到连接就开事务、慢慢干活、忘了提交」是最危险的反模式之一。VACUUM 与回收水平线的完整机制，是第 3 章的正题（详见 第 3 章 · 可见性图与回收）。

§7动手观察：两个会话看快照如何隔离

把 §1–§3 拧成一个可观察的双会话实验。两栏分别是会话 A 和会话 B；先用默认的 Read Committed 看「B 看不到 A 的未提交、A 一提交 B 就看见」，再切到 Repeatable Read 看「B 钉住快照后，A 提交了 B 仍看不见」。下面的输出未在本机执行，用于演示该看哪些时刻、结果如何随快照时机变化。

-- 会话A                                  -- 会话B
BEGIN;
INSERT INTO accounts (id, balance)
  VALUES (2, 50.00);
-- 尚未 COMMIT
                                          -- 会话B（默认 Read Committed）
                                          SELECT * FROM accounts WHERE id = 2;
                                          --  id | balance
                                          -- ----+---------
                                          -- (0 rows)        <- 看不见 A 的未提交版本
COMMIT;
                                          -- A 提交后，B 再查（新语句 = 新快照）
                                          SELECT * FROM accounts WHERE id = 2;
                                          --  id | balance
                                          -- ----+---------
                                          --   2 |   50.00   <- 现在看见了（未在本机执行）

-- 会话A                                  -- 会话B
                                          BEGIN ISOLATION LEVEL REPEATABLE READ;
                                          -- 第一条 SELECT 拍下整事务沿用的快照
                                          SELECT count(*) FROM accounts;
                                          --  count
                                          -- -------
                                          --      2          <- 此刻的视图被钉住
BEGIN;
INSERT INTO accounts (id, balance)
  VALUES (3, 70.00);
COMMIT;
                                          -- A 已提交，但 B 仍用最初那张快照
                                          SELECT count(*) FROM accounts;
                                          --  count
                                          -- -------
                                          --      2          <- 仍看不见 id=3（未在本机执行）
                                          COMMIT;  -- 事务结束，下次新事务才会看到

逐行解读，把每个时刻映射回概念：

• B 第一次查 = 空A 的 INSERT 还没 COMMIT，那个新 tuple 的 xmin 对应的事务在 B 的快照里属于「仍在进行」（落在 xip[]）。按 §2 的规则，创建者未提交 → 不可见。对上 §1 的 xip[]。
• A COMMIT → B 看见B 是 Read Committed，第二条 SELECT 重新拍了一张快照（§3 的「每语句新快照」）。这一刻 A 已提交，新 tuple 的创建者不再在 xip[] 里 → 可见。两次结果不同，正是「不可重复读」。
• RR 下 B 第一条 SELECTBEGIN ISOLATION LEVEL REPEATABLE READ 后的第一条语句拍下快照，整事务沿用（§3 的快照隔离）。这张快照的 xmax 上界，定格在那一刻。
• RR 下 A 提交后 B 仍 = 2A 的事务 xid 大于等于 B 快照的 xmax 上界，无论它是否提交，对 B 这张钉住的快照一律不可见（§2）。所以 count 不变——这就是 RR 消除不可重复读的机制：不是「锁住了行」，而是「快照根本没把后来的事务纳入视野」。