行版本链与可见性判断是MVCC核心机制：修改生成tempdb中带XSN和前序指针的版本链，查询依事务快照（Min/Max XSN）从新到旧取首个已提交且未被后续删除的版本。
sql数据库中行版本链（Row Version Chain）和可见性判断是实现多版本并发控制（MVCC）的核心机制，尤其在 SQL Server、postgresql 等支持快照隔离的系统中至关重要。理解其结构与判断流程，有助于排查阻塞、长事务、版本存储膨胀等问题。
行版本链的物理结构
当开启快照隔离（如 READ_COMMITTED_SNAPSHOT 或 ALLOW_SNAPSHOT_ISOLATION）后，对数据行的每次修改（UPDATE/delete）不会直接覆盖原行，而是在 tempdb 的版本存储区（Version Store）中生成新版本，并通过指针链接成链：
- 每行数据页中保留一个 14 字节的版本标记（Version pointer），指向 tempdb 中最新版本的地址；
- 每个版本记录包含：事务序列号（XSN）、前一版本指针（Previous Version Pointer）、实际数据内容（仅变更列或整行，依实现而定）；
- 链头是当前最新已提交版本，链尾是原始基表行（即未被覆盖的“老”行），形成从新到旧的单向链；
- DELETE 操作也生成版本（逻辑删除），UPDATE 是“删除+插入”组合，均产生新版本。
可见性判断的核心依据：事务快照与版本时间戳
查询时，数据库根据当前事务启动时刻的快照（Snapshot），结合各版本的事务提交时间戳（Commit timestamp / XSN），决定哪些版本对该事务“可见”：
- 事务启动时，系统记录其 快照范围：最小活跃事务 ID（Min Active XSN）和最大已提交事务 ID（Max Committed XSN）；
- 遍历行版本链时，逐个检查每个版本的 提交事务 ID（对 INSERT/UPDATE 是写入事务的 commit XSN；对 DELETE 是删除事务的 commit XSN）；
- 可见规则（以 SQL Server 快照隔离为例）：
– 若版本的 commit XSN ≤ 当前事务快照的 Max Committed XSN，且 ≥ Min Active XSN（即该版本在事务开始前已提交，且未被更早未结束事务覆盖），则可能可见；
– 更精确地：版本必须由 在当前事务开始前已提交 的事务生成，且 未被在当前事务开始后才提交的事务所删除（即删除版本的 commit XSN 必须 > 当前事务快照时间点）； - 最终只取满足条件的“最新可用版本”——即链上第一个满足可见性条件的版本（从新往旧扫描）。
常见影响可见性的关键因素
可见性不是静态的，会随系统状态动态变化：
- 长时间运行的事务：会抬高 Min Active XSN，导致大量旧版本无法被清理，tempdb 版本存储持续增长；
- 未提交的写事务：即使只 UPDATE 一行未 COMMIT，也会阻塞其他事务读取该行的新版本（因删除版本尚未提交，其可见性不确定）；
- 事务隔离级别差异：READ COMMITTED（启用 RCSI）用语句级快照；SNAPSHOT ISOLATION 用事务级快照；REPEATABLE READ 和 SERIALIZABLE 不依赖版本链，走锁机制；
- 版本清理延迟：只有所有依赖该版本的事务都结束，后台 cleanup 线程才会释放 tempdb 中对应空间。
诊断与验证方法
可通过系统视图观察版本链与可见性行为：
- sys.dm_tran_version_store：查看当前版本存储中的所有行版本（含事务 ID、数据库 ID、rowset ID、XSN）；
- sys.dm_tran_active_snapshot_database_transactions：查出所有启用快照的活跃事务及其快照信息（first_snapshot_sequence_num, min_transaction_seqnum）；
- DBCC PAGE (dbid, fileid, pageid, 3)：在行所在数据页中查看 version pointer 值，再结合 sys.dm_tran_version_store 关联定位链上版本；
- 使用 READ_COMMITTED_SNAPSHOT ON 后，原行的行首增加 14 字节版本指针，可通过 DBCC PAGE 观察结构变化。