★ FEATURED ARTICLE 干活的时候被问到一个问题“PostgreSQL 里 xmax 到底是干嘛的什么时候写什么时候清”我当时第一反应是背 MVCC 八股文但真上手查了一下午发现这东西远不止“删掉的行打个标记”那么简单。今天就把我实际翻源码、开 pageinspect、做压测实验的过程整理出来把 xmax 从概念到实操一次说透。先说结论xmax 是 PostgreSQL MVCC 体系里最容易被误解的字段。很多人把它当“删除标记”其实它在不同场景下扮演三种完全不同的角色——已删除行的终结者、行级锁的持有者、以及更新操作中的旧版本标记。理解不了这三种身份的切换就理解不了 PostgreSQL 的并发控制。1. xmax 概念辨析先搞懂它和 xmin 的分工1.1 从一行数据的生命周期说起在 PostgreSQL 的堆表存储结构里每个行版本tuple头部都有两个关键系统字段xmin 和 xmax。xmin 记录的是“谁创造了这个版本”xmax 记录的是“谁终结了这个版本”。听起来很简单但“终结”这个词伸缩性极大——可能是一个 DELETE 命令也可能是一个 UPDATE 命令在旧版本上留下的“此路不通”标记还可能是一个事务在行上加了行级锁。举一个最直观的例子。假设有一个用户表一行数据最初由事务 ID 100 插入xmin 100, xmax 0此时这行是“活的”xmax 为 0 表示没有事务宣告要终结它。接着事务 200 执行 UPDATE把这行的 name 字段改了。物理上PostgreSQL 不是原地修改而是插入了一个新版本并把旧版本的 xmax 设为 200旧版本xmin 100, xmax 200 新版本xmin 200, xmax 0对旧版本来说xmax 200 并不是真正的“删除”而是“有一个事务在 200 时把这个版本作废了”。只要事务 200 还没提交旧版本理论上还有“复活”的可能如果 200 回滚。这就是“终结”这个词的微妙之处xmax 指向的事务可能还没结束所以这个版本是否真的死了取决于 xmax 事务的最终状态。1.2 xmax 不等于“删除标记”的三个理由很多人把 xmax 理解为“这行被删了”这有三大误区xmax 可能是行锁标记。如果事务 200 只是执行了SELECT ... FOR UPDATE并没有修改任何字段新版本不会产生——因为行内容没变但 xmax 会被设为 200表示“这个行版本被事务 200 锁住了”。这种情况下行数据完全没变但并发控制必须靠这个字段发挥作用。xmax 指向的事务可能已回滚。如果事务 200 在更新后回滚了旧版本上的 xmax 200 就变成一个“无效终结”因为 200 的修改从未生效。此时 xmax 的值还在但通过 CLOG提交日志判断出事务 200 已回滚后这行旧版本的 xmax 在逻辑上等于 0行依然是活跃的。xmax 可能被多事务共享。当多个事务同时FOR UPDATE同一行时xmax 会被写成一个“多事务 ID”MultiXactId而不是单一事务 ID。这时候 xmax 的值不是某个事务的 ID而是一个指向多事务槽位的 ID槽位里记录了哪些事务参与了锁竞争。搞清楚这三点才不会被某些监控工具显示的 xmax 数值误导。我见过有人直接拿xmax字段值当“删除事务 ID”去做数据恢复结果连行级锁都可能解不开。1.3 xmax 在 MVCC 可见性判断中的位置MVCC 的可见性规则核心是一个行版本对某个事务是否可见取决于 xmin 是否已提交、以及 xmax 是否指向一个已提交的事务。判断流程大致如下如果 xmin 对应的事务未提交这个行版本对任何其他事务都不可见可能是正在插入中的数据。如果 xmin 已提交再检查 xmaxxmax 0行版本活跃可见。xmax 指向的事务未提交行版本被“正在进行中的操作”影响不可见但可能被等待锁等待。xmax 指向的事务已提交且是删除操作行版本已死不可见。xmax 指向的事务已提交但是更新操作需要顺着版本链找下一个版本继续判断。这里面最关键的就是“xmax 指向的事务已提交后到底对应什么操作”。DELETE 和 UPDATE 在 xmax 层面表现出不同的后续行为DELETE 的旧版本彻底死了UPDATE 的旧版本只是“让位”给新版本新版本通过版本链t_ctid找到。这就是为什么 CLOG 和快照snapshot在可见性判断中如此重要——单看 xmax 字段本身你无法判断它背后的真实语义。必须结合事务状态和元组头部的 t_infomask 标志位。2. xmax 与行锁机制并发控制中的开关与信号灯2.1 行级锁的底层全靠 xmax 撑着PostgreSQL 的行级锁并没有单独的行锁表而是直接复用元组的 xmax 字段。当一个事务执行SELECT ... FOR UPDATE、FOR SHARE或UPDATE、DELETE时如果目标行没有被其他事务锁定它就直接把自己的事务 ID 写入 xmax。这个设计的精妙之处在于锁信息就在数据行本身不需要额外的锁管理器存储可以一劳永逸地避免锁表膨胀问题。但也带来一个代价——行锁就是数据行版本状态的一部分一旦写入 xmax就得跟着事务生命周期走事务提交或回滚后要清理或保留该标记。行锁存储机制有一个特殊点已经被删除的行xmax 不能再被当作锁标记因为行已经进入“死”状态锁竞争在删除那一刻就已经通过其他机制处理完了。所以你会看到一种情况A 事务删除了一行但还没提交B 事务尝试更新同一行时不会等待 A——它看到的是 xmax 指向未提交事务且该事务做的是删除操作B 会直接对这个行版本做“等待”直到 A 提交或回滚。2.2 FOR UPDATE 场景下的 xmax 行为做一个实验来演示行锁和 xmax 的关系。建一张测试表并插入一行数据CREATE TABLE t_lock (id int primary key, name text); INSERT INTO t_lock VALUES (1, alice);当前该行 xmin 是当前事务 IDxmax 为 0。开启一个事务但不提交BEGIN; SELECT * FROM t_lock WHERE id 1 FOR UPDATE;此时查看该行的头部信息xmax 不再是 0而是当前事务 ID。这个 xmax 意味着“这个行版本被事务 X 锁持有”。另一个会话尝试更新该行时UPDATE t_lock SET name bob WHERE id 1;这个会话会进入阻塞等待因为它的更新操作试图把新事务 ID 写到 xmax但 xmax 已经被事务 X 占用且 X 尚未结束。它只能等待事务 X 提交或回滚。事务 X 提交后等待中的更新会获取到锁然后执行真正的版本更新。事务 X 回滚的话锁自动释放等待中的更新会拿到当前版本并成功写入自己的 xmax。整个过程中 xmax 就是一个“谁在动这行”的指针。2.3 多事务锁的 MultiXactId 机制如果多个事务同时对同一行加锁xmax 字段的能力就捉襟见肘了——它只能存储一个事务 ID。PostgreSQL 用一个巧妙的方式解决xmax 不再存储事务 ID而是存储一个 MultiXactId指向共享内存中的一个多事务槽分为成员列表和状态表两部分。典型场景事务 A 执行SELECT ... FOR UPDATE锁定了某行之后事务 B 也执行SELECT ... FOR UPDATE此时 B 会等待 A 释放锁。A 释放后 B 获取锁。如果 A 不释放而是又出现事务 C 执行同一个语句怎么办当多个事务并发请求同一行锁时PostgreSQL 会把它们的 ID 聚合到一个 MultiXactId 中xmax 更新为该 MultiXactId。读取 MultiXactId 时PostgreSQL 会沿着槽位找到所有成员事务逐一检查每个事务的状态以确认当前行锁是否已被释放。这个机制保证了“一组事务共同持有一把锁”的正确语义只有当所有成员事务都提交或回滚后锁才算释放。调试 MultiXact 状态时可以用这个查询SELECT * FROM pg_multixact;或者在pg_class里查看SELECT relname, relminmxid, relfrozenxid FROM pg_class WHERE relname t_lock;实际运维中我见过因为多事务槽饱和导致的“multixact wraparound”问题这通常发生在大量短事务反复更新同一行时。定期监控relminmxid和系统库的pg_multixact状态是预防这类问题的关键。2.4 锁等待、死锁与 xmax 的关联死锁检测器依赖的锁等待信息本质上就是通过元组的 xmax 对应的锁持有者来构建等待图的。如果两个事务分别持有一行的 xmax同时又在等待对方持有的另一行的 xmax死锁检测器就能发现环。当死锁发生时PostgreSQL 会选择回滚其中一个事务来打破死锁。被回滚的事务的 xmax 标记会随事务回滚而无效化——注意这不是立即清除 xmax 字段而是在逻辑上使它失效。后续事务再判断时发现 xmax 指向一个已回滚事务就认为锁已释放。这个设计有一个实际影响某些场合下你会发现锁已经不存在了但 xmax 字段依然保留着指向已回滚事务的值。这种残留 xmax 不影响正确性但会带来额外的“判断成本”——每次可见性判断都要去查一次事务状态。大量这种残留标记会让 VACUUM 更加积极地去回收版本。3. 从源码与实战看 xmax 的写入、清除与应用3.1 元组头部的 t_infomask 位xmax 语义的前置开关理解 xmax 的真正含义必须同时看元组头部标志位 t_infomask。PostgreSQL 在判断 xmax 语义时不是直接看 xmax 值而是先看标志位HEAP_XMAX_IS_MULTIxmax 存的是 MultiXactId而不是单个事务 ID。HEAP_XMAX_LOCK_ONLYxmax 只表示行锁没有真正的行更新或删除。HEAP_XMAX_KEYSHR_LOCK/HEAP_XMAX_EXCL_LOCK锁类型分别对应FOR SHARE和FOR UPDATE等。HEAP_XMAX_COMMITTEDxmax 对应事务已提交可以据此判断版本的最终状态。这里有一个非常实际的调试技巧用pageinspect扩展直接查看元组头部能同时看到 xmax 和 t_infomask 的真实值。这才是排查问题的第一手资料而不是用 SQL 里的xmax系统列——因为它只显示一个数字无法告诉你这个数字是事务 ID、MultiXactId 还是已提交的终结者。3.2 INSERT、UPDATE、DELETE 三种操作对 xmax 的写入路径不同操作对 xmax 的写入路径截然不同INSERT新元组的 xmax 0因为新元组还没有被任何事务终结。如果插入后立即更新或删除该行那么在新事务中对应操作的旧版本会获得新的 xmax但新版本自己的 xmax 还是 0。UPDATEPostgreSQL 执行更新时会创建一个新元组xmin 当前事务xmax 0并将旧元组的 xmax 设为当前事务。这里有一个关键细节如果更新没有改变被索引的键值索引项会指向新元组旧元组的索引项保留并指向旧元组如果键值变了索引会额外做一次插入和删除。但无论如何旧元组的 xmax 都记录着这次更新的“作废者”。DELETE元组不新版本产生直接在当前元组上写 xmax 删除事务 ID。删除操作的 xmax 与更新的 xmax 在源码层面走的是同一条路径——heap_delete和heap_update都调用了HeapTupleHeaderSetXmax。“更新删除插入”这种误解其实并不准确。PostgreSQL 的更新本质是“插入新版本 旧版本标记为已作废”但旧版本不会立刻消失它会一直存在到 VACUUM 清理。如果频繁更新同一行就会有大量“旧版本挂链”的现象这也被称为“版本膨胀”或“表膨胀”。3.3 VACUUM 如何清理 xmax 残留VACUUM 清理元组时核心任务就是识别哪些元组的“死亡”状态是永久性的。判断依据是xmax 指向的事务已提交且不是锁标记则该元组可以被标记为 Dead如果 xmax 指向的事务还没结束或 xmax 是一个行锁标记则元组不能清理。这里有个重要机制VACUUM 不会把所有的“死元组”都立即物理删除。它会维护一个“死亡元组列表”dead tuple list并通过 Hint Bits 机制加速后续判断。如果 VACUUM 发现一个元组的 xmax 事务已经提交它会顺便把HEAP_XMAX_COMMITTED这个位设置上这样下次判断可见性时不需要再查 CLOG直接看标志位即可。这就是为什么你执行VACUUM后再查某些行的 xmax发现数值还在但查询速度变快了——因为后续判断不再需要去 CLOG 里反复确认 xmax 事务的状态。这类“提示位”机制是 PostgreSQL 性能优化中很关键的细节。清理的边界条件是“元组不能再被任何活跃事务看到”。这个判断依赖当前系统的快照信息。所以高并发下 VACUUM 的效率会变差——因为总有一些事务持有旧快照导致旧版本不能被标记为可清理。3.4 用 pageinspect 实地观察一行数据的 xmax 变化用实例演示如何把理论变成实操。先安装扩展CREATE EXTENSION IF NOT EXISTS pageinspect;查询表所在的页和元组偏移量SELECT ctid, xmin, xmax, * FROM t_lock;然后拉起页数据看原始头部SELECT * FROM heap_page_items(get_raw_page(t_lock, 0));输出中会有t_xmin、t_xmax、t_field3等字段t_field3里包含了t_infomask信息。执行一次UPDATE后再查你会看到旧元组的 t_xmax 变成了新事务 ID新元组的 t_xmin 变成了同一个事务 IDt_xmax 为 0。这里我踩过一个坑直接在 SQL 里用SELECT xmax FROM t_lock看到的是“该系统列在当前快照下的解读”并不是物理头部原始值。如果该行已被一个未提交事务删除xmax可能显示为删除事务 ID但如果该事务已提交并完成 VACUUMxmax 在系统列层面可能已经显示为 0而物理页内的 t_xmax 仍保留数值。排查问题时一定要分清楚你在看哪个层面。4. xmax 常见问题与调优实战4.1 问题速查xmax 相关现象与对策实际运维中常见的 xmax 相关现象主要有这么几类整理成表格方便对照排查现象可能原因排查手段应对方案行锁等待严重长事务未提交/回滚持有了 xmaxpg_stat_activity 查活跃事务杀掉长事务或优化事务时长表膨胀严重大量 UPDATE/DELETE 留下死版本pg_stat_user_tables 查 n_dead_tup提高 autovacuum 频率或手动 VACUUMmultixact 环绕大量并发锁同行导致多事务槽耗尽查 pg_multixact 状态调大 vacuum_multixact_freeze_min_age可见性判断慢缺少 hint bits频繁查 CLOG查看 t_infomask 位执行 VACUUM 主动写入 hint bits数据恢复时误读 xmax把锁标记当删除标记检查 t_infomask 位使用 pg_xact 配合事务状态分析4.2 自动清理阈值为什么 VACUUM 总“看起来没干活”很多人抱怨 autovacuum 没执行或者执行了还是膨胀。核心原因大概率出在 xmax 相关版本回收的临界条件上如果一个长事务一直持有旧快照它就能“看到”所有旧版本这些版本全部不能清理即使 autovacuum 触发了也只能打个折扣。用这个 SQL 查死元组比例SELECT relname, n_live_tup, n_dead_tup, round(n_dead_tup::numeric / greatest(n_live_tup n_dead_tup, 1), 4) AS dead_ratio, last_autovacuum FROM pg_stat_user_tables ORDER BY dead_ratio DESC;当这个比例持续走高但 last_autovacuum 不变时优先检查是否有长事务、长时间空闲的事务连接占据了快照。找到后 kill 掉再手动触发 VACUUM膨胀问题往往立刻缓解。这种情况下你看到的很多 xmax 残留其实都是被长事务“保住”的死元组。4.3 监控 xmax 与事务 ID 回卷的预警事务 ID 是 32 位整数会回卷。PostgreSQL 用frozenxid机制标记“所有早于某事务的元组都已经是提交状态无需再比较事务 ID”。这个过程中 xmax 也是参与方——当一个被删除元组的 xmax 事务已经“足够老”VACUUM 可以直接将其标记为已死并清理而不需要保留精确的事务 ID。警惕这类现象pg_class 里 relfrozenxid 不断增长但从不下降说明有大量旧元组没被冻结。配合 xmax 相关查询可以定位到具体表SELECT relname, age(relfrozenxid) AS frozen_age, age(relminmxid) AS multixact_age FROM pg_class WHERE relkind r AND relname NOT LIKE pg% ORDER BY age(relfrozenxid) DESC LIMIT 10;一旦frozen_age接近2^31就要立刻处理否则可能触发事务 ID 回卷保护性停机。这种故障恢复起来极其痛苦我建议在运维监控里单独加一条针对age(relfrozenxid)的告警线。4.4 实际调优案例一次行锁引起的连环雪崩某次线上事故现象是业务接口大面积超时数据库 CPU 不高但活跃会话数持续打满。排查时发现几百个会话都卡在同一条 UPDATE 上。查看pg_stat_activity这些会话的 wait_event 全是transactionid意思是都在等待某个事务 ID。顺着 wait_event 找到持有该事务 ID 的会话——是一个空事务已经 idle in transaction 超过半小时。由于它没有做任何写操作却持有了事务快照和行级锁xmax 标记导致所有需要更新同一行的请求全部排队。处理办法kill 掉空闲事务阻塞立刻解除。后续优化点是给应用层设置事务超时超过阈值的连接强制回收。把idle_in_transaction_session_timeout设成一个合理值。对关键行的更新操作重试间隔加抖动避免所有请求同时争抢同一行。这个事故教会我一个经验xmax 在行锁场景下不只是字段值它是整个等待链路的源头。排查锁问题时第一步永远是找“xmax 对应的那个事务 ID 是谁”然后判断它为什么迟迟不结束。4.5 与 VACUUM 冻结参数的协同经验调参前先理解这几个参数的分工参数作用autovacuum_freeze_max_age触发防止事务 ID 回卷的 autovacuum 阈值vacuum_freeze_min_ageVACUUM 时标记为冻结的最小事务年龄vacuum_multixact_freeze_min_ageMultiXactId 推出的最小年龄autovacuum_multixact_freeze_max_age触发多事务回卷保护的阈值实际项目中如果一个表更新频繁但事务都很短可以适度调大autovacuum_freeze_max_age减少不必要的大规模 “freeze” 扫描。反之如果表很少更新但读取多建议调小vacuum_freeze_min_age让旧版本尽快被冻结减少可见性判断的链式比较。调参的验证方式是观察pg_stat_progress_vacuum和系统日志里的 “automatic vacuum of table ...” 记录统计每条 VACUUM 清理了多少 dead tuples、耗时多少。调完再跑一轮看数据变化而不是凭感觉。5. xmax 相关的深层话题从版本链到逻辑复制5.1 HOT 更新与 xmax为什么索引膨胀有时候不明显HOTHeap-Only Tuple更新是 PostgreSQL 在低版本更新时的优化如果更新不涉及索引键列并且旧版本所在页有足够空间新版本就放在同一页内并通过旧版本的 t_ctid 指向新版本形成一条“版本链”。在 HOT 链中xmax 的作用仍然是标记旧版本的无效状态但索引项不需要变更——索引依然指向链头通过版本链找到最新版本。这种更新方式大幅降低了索引维护开销也是为什么有些表更新频繁但索引膨胀不严重。调试 HOT 更新时页面的t_ctid指向自己所在页的另一个偏移量t_infomask中会设置HEAP_HOT_UPDATED和HEAP_ONLY_TUPLE标志。xmax 即使被写入也不会立即要求索引同步。这就是 HOT 的精髓把版本更新的索引开销省掉用元组自身的链式结构保证查询正确性。5.2 逻辑复制与 xmax 的“不可见”边界逻辑复制基于 WAL 日志解析变更发布端发出的变更不直接包含物理元组头部的 xmax。但解码过程依赖 xmax 判断“某行是否被删除或更新”。具体来说逻辑复制解析时如果检测到一个元组被 UPDATE会先读取旧版本的 xmax然后从新版本中读取完整数据DELETE 解析同理。因此如果发布端表存在大量版本膨胀xmax 残留多逻辑复制解码器的扫描效率会下降因为它在解析每个变更时需要额外判断版本链的有效性和 xmax 状态。这也解释了为什么发布端与订阅端的延迟有时不是网络问题而是发布端的版本膨胀问题。如果你在做逻辑复制的性能调优查一下发布端的n_dead_tup和版本链长度往往比查订阅端消费速度更有价值。5.3 从 xmax 引申Hot Standby 下的冲突处理在主备复制架构下备库上运行的查询可能会因为主库的删除或更新操作产生冲突。备库回放 WAL 时如果发现需要访问的元组已经被主库的新变更覆盖xmax 已更新就会产生冲突。备库查询必须取消才能继续追平主库。为了减少这类冲突PostgreSQL 提供了max_standby_streaming_delay和max_standby_archive_delay参数控制备库在遇到冲突时等待的时间。这个等待窗口本质上是给查询一段时间来完成对旧版本的读取尽可能避免中断。但等待不等于无限期超过阈值就会强制取消查询。所以你会发现备库上长查询的频繁中断往往是主库上某行的 xmax 持续被刷新导致的。此时优化方向是要么控制主库对关键行的更新频率要么调整备库冲突延迟参数要么在应用层拆分长查询。理解了 xmax 的语义你就能明白为什么一个 UPDATE 操作会在备库上造成如此大的影响——它不仅仅是一个 WAL 变更还牵动着 MVCC 可见性的完整链条。最后分享一个排查经验xmax 相关的故障大多数不是 xmax 本身出了问题而是围绕它的生命周期管理没做好。长事务拖着锁不释放、VACUUM 触发的太晚、旧快照被长时间持有——每种情况最终都会以“xmax 标记大量残留”或“等待 xmax 对应事务”的形式暴露出来。我个人常用的排查“三板斧”是先查pg_stat_activity看活跃事务和 wait_event再查pg_stat_user_tables看死元组比例最后用pageinspect直接看物理元组的 t_xmax 和 t_infomask。这三步走完绝大多数 xmax 相关的问题都能定位到根因。盲目调参数解决不了根本问题先看清数据再动手才是不二法门。
阅读完成 · 觉得有帮助？
