PostgreSQL MVCC 深度解析摘要本文通过每条元组头部的 t_xmin 和 t_xmax 字段解释 PostgreSQL 的多版本并发控制Multi-Version Concurrency Control在存储层的工作原理。展示了快照如何在并发会话之间确定可见性为什么 READ COMMITTED 和 REPEATABLE READ 隔离级别表现不同以及非阻塞读取与磁盘空间使用之间的权衡。原文链接你在一个 psql 会话中执行SELECT * FROM orders看到 5000 万行数据。另一个会话中的同事在同一时刻执行相同查询却看到 49,999,999 行。你们都没有错也没有看到过期数据。你们读取的是相同的 8KB 堆页面相同的磁盘字节。这就是 PostgreSQL MVCC多版本并发控制的承诺也是读操作永远不会阻塞写操作、写也永远不会阻塞读者的原因。这是存储引擎中最容易被误解的部分。人们知道一行数据有多个版本后就止步于此。答案就在每条元组的八个字节中。xmin 和 xmax唯二重要的两个 XID如果你读过《深入理解 8KB 页面》就知道每条元组以 23 字节的头部开始。头部的头八个字节是两个 32 位事务 IDt_xmin插入这个版本的 transaction和t_xmax删除或更新它的 transaction如果是 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) (2 rows)两条元组。都以t_xmin 100执行 INSERT 的事务和t_xmax 0没有人删除它们标记。在这个时刻数据库上的每个会话都会看到这些行因为所有人的快照都认定事务 100 已提交。现在打开两个并发会话。会话 A 执行一个未提交的 UPDATE-- session ABEGIN;UPDATEmvcc_demoSETvalalpha-newWHEREid1;-- do not commit yet再次查看页面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) (3 rows)一次 UPDATE三条元组。id1 的旧版本仍在行指针 1 处带有t_xmax 101的标记新版本在行指针 3 处t_xmin 101。会话 A 尚未提交。事务 101 仍在进行中。正在执行SELECT * FROM mvcc_demo的会话 B 仍然看到原始的alpha而不是alpha-new。三条元组都在页面上但会话 B 的快照认为 XID 101 正在进行中忽略了它所做的任何修改。可见性判断是实时进行的每次触碰元组时都会发生。这是 MVCC 反直觉的部分磁盘上的字节不会因为询问者的不同而改变。改变的是读取它们时规划器应用的可视性判决。快照pg_current_snapshot()是查看你的会话实际持有什么的最清晰方式。SELECTpg_current_snapshot();pg_current_snapshot --------------------- 101:103:101 (1 row)这是xmin:xmax:xip_list这就是整个快照xmin可能仍在进行中的最低 XID。低于此值的所有事务都已解决已提交或已中止。你可以信任它的 t_xmin/t_xmax 标记而无需进一步检查。xmax第一个尚未分配的 XID。等于此值或高于此值的任何值都不存在 yet。带有此值标记的元组必须被忽略。xip_listxmin 和 xmax 之间仍在运行的 XID。这些是进行中的事务它们的写入对你不可见。PostgreSQL 逐条元组地应用这个测试。如果你的快照认为t_xmin已中止或仍在进行中这条元组对你来说不存在PostgreSQL 会跳过它。如果t_xmin已提交则由t_xmax决定0 表示元组存活已提交的t_xmax表示有人删除了它你看不到进行中或已中止的t_xmax表示删除尚未到达你的快照。相同的页面。相同的字节。不同的会话有不同的快照所以对同一条元组会得出不同的结果。交互式 MVCC 可视化器针对同一个堆页面驱动两个并发会话。观察 xmin 和 xmax 标记的变化在 READ COMMITTED 和 REPEATABLE READ 之间切换逐条元组地追踪可见性规则并在死版本堆积时运行 VACUUM。打开可视化器READ COMMITTED 与 REPEATABLE READ 的区别PostgreSQL 两个最常用的隔离级别之间的差异归结为一个问题快照何时捕获READ COMMITTED默认在每个语句开始时捕获一个新的快照。如果另一个会话在你的第一个和第二个 SELECT 之间提交你的第二个 SELECT 会看到变化。世界在你的事务下逐语句前进。REPEATABLE READ在事务开始时捕获一个快照并在每个后续语句中重用它。从你的事务角度来看世界是冻结的。其他会话可以提交上千次更改你的查询持续返回在 BEGIN 时可见的内容。页面上的字节在两种情况下完全相同。唯一的区别是你的事务携带哪个快照。-- session A, READ COMMITTED (default)BEGIN;SELECTvalFROMmvcc_demoWHEREid1;-- alpha-- session B, in another terminal:UPDATEmvcc_demoSETvalalpha-newWHEREid1;-- (auto-commits)-- back in session A:SELECTvalFROMmvcc_demoWHEREid1;-- alpha-new new statement, new snapshotCOMMIT;用 REPEATABLE READ 重复-- session A, REPEATABLE READBEGINISOLATIONLEVELREPEATABLEREAD;SELECTvalFROMmvcc_demoWHEREid1;-- alpha-new-- session B:UPDATEmvcc_demoSETvalalpha-newerWHEREid1;-- (auto-commits)-- Back in session A:SELECTvalFROMmvcc_demoWHEREid1;-- still alpha-new same snapshot as BEGINCOMMIT;可视化器直接展示这一点每个会话上都有一个隔离级别选择器。在 REPEATABLE READ 下快照在 BEGIN 时捕获并持久化。在 READ COMMITTED 下每次运行 SELECT 时都会刷新。观察每条元组上的可见性标记如何相应地翻转。每次 UPDATE 都会留下死元组PostgreSQL 中的每次 UPDATE 都会创建一个新的元组版本。旧版本不会消失。它被标记上t_xmax并留在页面上占用空间直到 VACUUM 清理它。在有大量更新的繁忙表上死元组的堆积速度可能超过 VACUUM 清理的速度。这就是膨胀它是团队认为 Postgres 需要调优的最常见原因。MVCC 契约“永不阻塞始终提供一致的视图”是用磁盘空间支付的。可以看到死元组的堆积情况用pgstattupleCREATEEXTENSIONIFNOTEXISTSpgstattuple;-- After lots of updatesSELECTtable_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 (1 row) 三条死元组两条活元组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即 commit log。一旦找到答案它就将该答案缓存在元组的 t_infomask 位中HEAP_XMIN_COMMITTED 或 HEAP_XMIN_INVALID。未来的读者完全跳过 pg_xact 查找。 设置这些位是一次写操作。页面变脏了。最终被刷新。你无辜的 SELECT 最终触发了 I/O。 这就是为什么在冷表上运行 EXPLAIN (ANALYZE, BUFFERS) 有时会在计划只包含读取的情况下显示 dirtied 缓冲区。这也是为什么批量加载后的第一次查询模式有那个神秘的慢运行你要为在数千个新写入的页面上设置提示位支付一次性成本。参见[《理解 EXPLAIN Buffers》](/posts/explain-buffers/) 了解更多关于这些计数器如何显示的信息。 ## 一段话总结 MVCC 契约 每条元组携带 t_xmin 和 t_xmax。每个事务携带一个 (xmin, xmax, xip_list) 的快照。可见性是一个两阶段查找比较两者。UPDATE 和 DELETE 不就地修改字节。它们在旧版本上标记 t_xmax 并追加新版本。VACUUM 清理死版本但只能清理没有活动事务可能仍需要的那些。长时间运行的事务阻塞 VACUUM。每个 SELECT 第一次看到新数据时都可能弄脏一个页面因为它在提示位中缓存提交状态。 每条元组 8 字节的 XID加上每个事务一个三数快照加上一个可见性函数。这就是整个机制但后果蔓延到 PostgreSQL 运维的每个角落从膨胀监控到复制到 autovacuum 调优。 关于完整的字节级tour提示位编码、可见性图、冷冻、XID 回绕存储系列详细涵盖这些。如果你从未观察过 MVCC 的发生可视化器是建立直观理解最快的方式。让两个会话相互对抗切换隔离级别然后再回到这篇文章。