DeepSeek总结的PostgreSQL MVCC，逐字节解析

来源：https://boringsql.com/posts/postgresql-mvcc-byte-by-byte/

PostgreSQL MVCC，逐字节解析

2026-04-17 · Radim Marek

你在一个 psql 会话中运行SELECT * FROM orders，看到了 5000 万行。你的同事在另一个会话中同时运行相同的查询，却看到了 49,999,999 行。你们两个都没有错，也没有人看到过时的数据。你们都在读取相同的 8KB 堆页面，磁盘上相同的字节。

这就是 PostgreSQL 的 MVCC（多版本并发控制）的承诺，也是读者永不阻塞写者、写者永不阻塞读者的原因。它也是存储引擎中最容易被误解的部分之一。人们知道“一行有多个版本”，然后就止步于此。

答案存在于每个元组的八个字节中。

xmin 和 xmax：唯一重要的两个 XID

如果你读过《深入 8KB 页面》，就会知道每个元组都以一个 23 字节的头部开始。该头部的前八个字节是两个 32 位的事务 ID：t_xmin（插入此版本的事务）和t_xmax（删除或更新此版本的事务，如果仍然存活则为 0）。

这就是存储层面 MVCC 的核心。PostgreSQL 不维护一个单独的“当前版本”表。它不将任何行标记为“最新”。每个元组都携带自己的两字段时间戳，当你的查询读取一个页面时，PostgreSQL 必须逐个元组地决定你的事务是否被允许看到它。

一个最小的演示：

CREATETABLEmvcc_demo(idint,valtext);INSERTINTOmvcc_demoVALUES(1,'alpha'),(2,'beta');

使用pageinspect窥视原始页面：

SELECTlp,t_xmin,t_xmax,t_ctidFROMheap_page_items(get_raw_page('mvcc_demo',0));lp|t_xmin|t_xmax|t_ctid----+--------+--------+--------1|100|0|(0,1)2|100|0|(0,2)(2rows)

两个元组。都标记了t_xmin = 100（执行INSERT的事务）和t_xmax = 0（没有人删除它们）。此时，数据库上的每个会话都会看到这些行，因为每个会话的快照都一致认为事务 100 已提交。

现在打开两个并发会话。会话 A 运行一个UPDATE但不提交：

-- 会话 ABEGIN;UPDATEmvcc_demoSETval='alpha-new'WHEREid=1;-- 先不要提交

再次窥视页面：

SELECTlp,t_xmin,t_xmax,t_ctidFROMheap_page_items(get_raw_page('mvcc_demo',0));lp|t_xmin|t_xmax|t_ctid----+--------+--------+--------1|100|101|(0,3)2|100|0|(0,2)3|101|0|(0,3)(3rows)

一次UPDATE，三个元组。id=1的旧版本仍在行指针 1 处，标记了t_xmax = 101，而新版本位于行指针 3 处，标记了t_xmin = 101。

会话 A 尚未提交。事务 101 仍在进行中。会话 B 现在运行SELECT * FROM mvcc_demo，仍然看到原始的alpha，而不是alpha-new。这三个元组都存在于页面上，但会话 B 的快照认为 XID 101 正在进行中，因此忽略它所做的一切。可见性决策在每次触碰元组时实时发生。

这就是使 MVCC 反直觉的部分：磁盘上的字节不会根据谁在询问而改变。改变的是规划器在读取它们时应用的可见性判定。

快照

pg_current_snapshot()是查看你的会话实际持有的快照的最清晰方式。

SELECTpg_current_snapshot();pg_current_snapshot--------------------101:103:101(1row)

这是xmin:xmax:xip_list，构成了整个快照：

• xmin：可能仍在进行中的最小 XID。所有低于此值的 XID 已经确定（已提交或已中止）。你可以信任它们的t_xmin/t_xmax标记，无需进一步检查。
• xmax：第一个尚未分配的 XID。任何大于等于此值的 XID 尚不存在。标记有此 XID 的元组必须被忽略。
• xip_list：介于xmin和xmax之间、且仍在运行的 XID。这些是“进行中”的事务，它们的写入对你不可见。

PostgreSQL 逐个元组地应用这个测试。如果你的快照认为t_xmin已中止或仍在进行中，则该元组对你来说不存在，PostgreSQL 会跳过它。如果t_xmin已提交，则由t_xmax决定：零表示元组存活，一个已提交的t_xmax表示有人已删除它，你看不到它，而一个进行中或已中止的t_xmax表示删除操作尚未进入你的快照。

相同的页面。相同的字节。不同的会话有不同的快照，因此它们对同一个元组得出不同的结果。

交互式 MVCC 可视化工具

驱动两个并发会话针对同一个堆页面。观察xmin和xmax标记的变化，在READ COMMITTED和REPEATABLE READ之间切换，逐个元组追踪可见性规则，并在死版本堆积时运行VACUUM。

打开可视化工具

READ COMMITTED 与 REPEATABLE READ

PostgreSQL 最常用的两种隔离级别之间的区别归结为一个问题：快照是什么时候捕获的？

• READ COMMITTED（默认）在每个语句开始时捕获一个新的快照。如果另一个会话在你的第一个SELECT和第二个SELECT之间提交了更改，你的第二个SELECT会看到更改。世界在你的事务下逐语句地向前发展。

• REPEATABLE READ在事务开始时捕获一个快照，并在后续每个语句中重复使用它。从事务的角度看，世界被冻结了。其他会话可以提交一千个更改；你的查询始终返回在BEGIN时可见的内容。

页面上的字节在两种情况下完全相同。唯一的区别是你的事务携带的是哪个快照。

-- 会话 A, READ COMMITTED (默认)BEGIN;SELECTvalFROMmvcc_demoWHEREid=1;-- 'alpha'-- 会话 B, 在另一个终端中：UPDATEmvcc_demoSETval='alpha-new'WHEREid=1;-- (自动提交)-- 回到会话 A:SELECTvalFROMmvcc_demoWHEREid=1;-- 'alpha-new' 新语句, 新快照COMMIT;

现在用REPEATABLE READ重复：

-- 会话 A, REPEATABLE READBEGINISOLATIONLEVELREPEATABLEREAD;SELECTvalFROMmvcc_demoWHEREid=1;-- 'alpha-new'-- 会话 B:UPDATEmvcc_demoSETval='alpha-newer'WHEREid=1;-- (自动提交)-- 回到会话 A:SELECTvalFROMmvcc_demoWHEREid=1;-- 仍然是 'alpha-new' 与 BEGIN 时相同的快照COMMIT;

可视化工具直接展示了这一点：每个会话上都有一个隔离级别选择器。在REPEATABLE READ下，快照在BEGIN时捕获并持续存在。在READ COMMITTED下，每次运行SELECT时都会刷新。观察每个元组上的可见性徽章如何相应变化。

每次 UPDATE 都会留下一个死元组

PostgreSQL 中的每次UPDATE都会创建一个新的元组版本。旧版本不会消失。它被标记上t_xmax并停留在页面上，占用空间，直到VACUUM过来回收它。

在一个更新频繁的繁忙表上，死元组的累积速度可能超过VACUUM清理的速度。这就是“膨胀”，也是团队认为 Postgres 需要重新调优的最常见原因之一。MVCC 的契约（“永不阻塞，始终提供一致视图”）是以磁盘空间为代价的。

你可以使用pgstattuple看到死元组的累积：

CREATEEXTENSIONIFNOTEXISTSpgstattuple;-- 大量更新之后SELECTtable_len,tuple_count,dead_tuple_count,dead_tuple_percentFROMpgstattuple('mvcc_demo');table_len|tuple_count|dead_tuple_count|dead_tuple_percent-----------+-------------+------------------+--------------------8192|2|3|42.15(1row)

三个死元组，两个活元组，42% 的页面空间被浪费。这 42% 的空间将一直浪费，直到VACUUM运行，或者直到下一次触碰此页面的查询注意到死空间并触发页面级清理。

xmin 边界

VACUUM只能在没有运行中的事务可能还需要看到它时回收一个死元组。如果会话 B 在五分钟前启动了一个REPEATABLE READ事务并一直空闲，它的快照仍然认为id=1的更新前版本是存活版本。VACUUM不能触碰它，否则会破坏那个会话。

因此，VACUUM会找到系统上最旧的活动事务，并拒绝清理任何比它新的事物。一个长时间运行的REPEATABLE READ事务（例如，一个需要一小时的分析查询）实际上固定住了该小时内产生的每个元组版本。表持续膨胀。Autovacuum 运行，发现没有它被允许清理的东西，然后退出。

长时间运行事务的问题不是 MVCC 的 bug。这正是 MVCC 按设计工作方式。“读者永不阻塞”的代价是读者可能阻塞清理。如果你曾经检查过行为失常的生产数据库上的pg_stat_activity，并发现一个空闲了 14 小时的idle in transaction，你就会知道这种情况。

可视化工具清晰地展示了这一点：在会话 B 中启动一个REPEATABLE READ事务，让会话 A 运行一堆UPDATE和COMMIT，然后点击VACUUM。回收计数不会包括会话 B 仍然可以看到的元组版本。

提示位：为什么 SELECT 可能弄脏页面

新写入后，第一个触碰该页面的SELECT可能导致该页面被写回磁盘。不是因为SELECT修改了任何数据，而是因为它设置了提示位。

当 PostgreSQL 遇到一个t_xmin = 101的元组，并且需要知道 101 是否已提交时，它并非神奇地知道。它必须在pg_xact（以前叫pg_clog），即提交日志中查找 101。一旦找到答案，它会将该答案缓存在元组的t_infomask位中（HEAP_XMIN_COMMITTED或HEAP_XMIN_INVALID）。未来的读者完全跳过pg_xact查找。

设置这些位是一次写入操作。页面因此变脏。它最终会被刷新。你无辜的SELECT最终触发了 I/O。

这就是为什么在一个冷表上执行EXPLAIN (ANALYZE, BUFFERS)有时会显示dirtied buffers，即使计划中只包含读取操作。这也是为什么“批量加载后的第一个查询”模式会出现神秘的慢速运行的原因：你正在为跨越数千个新写入页面设置提示位而支付一次性成本。参阅《理解 EXPLAIN Buffers》了解这些计数器如何显示。

一句话总结 MVCC 契约

• 每个元组携带t_xmin和t_xmax。
• 每个事务携带一个快照(xmin, xmax, xip_list)。
• 可见性是一个两阶段查找，比较两者。
• UPDATE和DELETE不原地修改字节。它们在旧版本上标记t_xmax并追加一个新版本。
• VACUUM清理死版本，但仅限于没有活动事务可能还需要它们。
• 长时间运行的事务会阻塞VACUUM。
• 每个SELECT在第一次看到新数据时都可能弄脏页面，因为它会将提交状态缓存到提示位中。

每个元组八个字节的 XID，加上每个事务三个数字的快照，再加上一个可见性函数。这就是整个机制，但其后果波及 PostgreSQL 操作的每一个部分，从膨胀监控到复制，再到 autovacuum 调优。

关于完整的字节级解析（提示位编码、可见性映射、冻结、XID 回卷），存储系列文章有详细介绍。如果你从未亲眼见证过 MVCC 的发生，可视化工具是建立直观理解的最快方式。让两个会话相互对抗，切换隔离级别，然后再回到这篇文章。