来源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 位的事务 IDt_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_demoSETvalalpha-newWHEREid1;-- 先不要提交再次窥视页面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三个元组。id1的旧版本仍在行指针 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 READPostgreSQL 最常用的两种隔离级别之间的区别归结为一个问题快照是什么时候捕获的READ COMMITTED默认在每个语句开始时捕获一个新的快照。如果另一个会话在你的第一个SELECT和第二个SELECT之间提交了更改你的第二个SELECT会看到更改。世界在你的事务下逐语句地向前发展。REPEATABLE READ在事务开始时捕获一个快照并在后续每个语句中重复使用它。从事务的角度看世界被冻结了。其他会话可以提交一千个更改你的查询始终返回在BEGIN时可见的内容。页面上的字节在两种情况下完全相同。唯一的区别是你的事务携带的是哪个快照。-- 会话 A, READ COMMITTED (默认)BEGIN;SELECTvalFROMmvcc_demoWHEREid1;-- alpha-- 会话 B, 在另一个终端中UPDATEmvcc_demoSETvalalpha-newWHEREid1;-- (自动提交)-- 回到会话 A:SELECTvalFROMmvcc_demoWHEREid1;-- alpha-new 新语句, 新快照COMMIT;现在用REPEATABLE READ重复-- 会话 A, REPEATABLE READBEGINISOLATIONLEVELREPEATABLEREAD;SELECTvalFROMmvcc_demoWHEREid1;-- alpha-new-- 会话 B:UPDATEmvcc_demoSETvalalpha-newerWHEREid1;-- (自动提交)-- 回到会话 A:SELECTvalFROMmvcc_demoWHEREid1;-- 仍然是 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事务并一直空闲它的快照仍然认为id1的更新前版本是存活版本。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 的发生可视化工具是建立直观理解的最快方式。让两个会话相互对抗切换隔离级别然后再回到这篇文章。