MVCC多版本并发控制是 PostgreSQL 系数据库并发能力的基石。但具体到「某个事务能不能看到某条数据」这个最基础的问题答案藏在元组版本链、事务快照和隔离级别的交叉判定逻辑里。本文完整拆解 HaishanDB 的元组可见性判定机制。HaishanDB 依靠元组多版本序列与当前事务快照两套数据结合事务隔离级别规则完成元组数据可见性判定。下面先交代核心数据来源和判定流程再逐一拆解所有场景。一、前置基础1. 核心数据来源每条逻辑数据会产生多条物理元组版本形成版本链表。例如数据项 Q 的版本序列 Q930、Q931、Q932、Q933、Q934其中数字 93* 代表生成该元组的事务 ID。可见性判定主要提取元组核心字段字段含义xmin创建该元组的事务 IDxmax删除/更新该元组的事务 IDcmin / cmax事务内的命令序号同时结合对应事务的提交、终止状态进行综合判断。事务快照snapshot是另一套关键数据。当前事务执行查询操作时会生成专属快照核心字段包括字段含义xmin快照中事务 ID 下限小于此值的事务均已提交xmax快照中事务 ID 上限大于等于此值的事务尚未开始xip活跃事务 ID 数组快照生成时正在运行的事务快照主要用于区分不同事务的执行时序、判定事务是否完成提交是多版本可见性比对的核心依据。2. 判定整体流程第一步提取目标数据的完整元组版本序列批量获取每条元组的 xmin、xmax、cmin、cmax 字段及对应事务运行状态。第二步获取当前事务的快照信息依托快照核心字段界定创建/修改元组的事务与当前事务的时序关系。第三步结合数据库不同事务隔离级别对应的可见性规则完成元组对当前事务是否可见的最终判定。3. 核心判定思路设定待判定元组为 tuple当前事务快照为 snapshot。整体判定逻辑基于元组自身 {xmin, xmax} 事务区间与快照 {xmin, xip, xmax} 事务区间进行范围匹配枚举所有可能的交集场景结合事务隔离级别规则逐一判定各场景下元组的可见性状态。二、分场景可见性判定完整规则以下将所有可能的可见性判定场景逐一展开每个场景给出判定结论和逻辑依据。场景 1xmin 事务未提交且异常终止元组对应的创建事务未正常完成提交数据有效性不成立。结论不可见。场景 2xmin 事务未提交且由当前事务/父子事务生成此场景下结合元组生成命令与快照生成的时序关系、元组 xmax 标记状态分为 6 个子场景。子场景 2.1生成元组的命令晚于快照生成当前事务生成快照时该元组尚未创建。结论不可见。子场景 2.2生成命令早于快照xmax 仅锁定、无更新当前事务可正常读取自身写入的未更新数据。结论可见。子场景 2.3生成命令早于快照xmax 标记多事务更新multi三种情况分别判定情况结论删除/更新事务不是当前事务可见规避脏读更新事务为当前事务且更新命令在快照生成后可见更新事务为当前事务且更新命令在快照生成前不可见子场景 2.4生成命令早于快照xmax 被非当前事务/异常父子事务删除终止状态的父子事务统一归类为非当前事务。删除事务已异常终止元组数据未被有效删除。结论可见。子场景 2.5生成命令早于快照xmax 被当前事务删除删除命令晚于快照生成快照生成时刻该元组尚未执行删除操作数据有效。结论可见。子场景 2.6生成命令早于快照xmax 被当前事务删除删除命令早于快照生成快照生成时刻该元组已完成删除操作数据失效。结论不可见。场景 3xmin 事务未提交非当前事务/父子事务创建外部未提交事务的 ID 必然大于快照 xmin。结合快照活跃事务状态分为两个子场景子场景 3.1xmin 存在于快照 xip 活跃事务数组受事务隔离级别约束当前事务无法读取其他事务未提交数据。结论不可见。子场景 3.2xmin 大于快照 xmax当前事务生成快照时该元组的创建事务尚未启动元组不存在。结论不可见。场景 4xmin 事务已提交xmin 快照 xmin元组创建事务已完成提交数据初始化有效。根据 xmax 标记的更新/删除事务状态细分为 5 个子场景。子场景 4.1xmax 无效无更新、无删除元组无任何后续修改、删除操作为当前有效最新版本。结论可见。子场景 4.2xmax 仅锁定、未执行更新元组仅被锁定无实际数据变更数据保持有效。结论可见。子场景 4.3xmax 标记多事务更新五种情况分别判定情况结论更新事务为当前事务更新命令在快照后可见更新事务为当前事务更新命令在快照前不可见更新事务非当前事务xmax 在快照 xip 内未提交可见更新事务非当前事务xmax 事务已提交不可见更新事务非当前事务xmax 事务异常终止可见子场景 4.4xmax 标记更新事务尚未提交四种情况分别判定情况结论更新事务为当前事务更新命令在快照后可见更新事务为当前事务更新命令在快照前不可见更新事务非当前事务xmax 在快照 xip 内未提交可见更新事务非当前事务xmax 事务未提交可见子场景 4.5xmax 标记更新事务已提交该元组已被其他事务更新并固化为有效数据当前元组为过期版本。结论不可见。总结HaishanDB 的 MVCC 元组可见性判定可以归纳为一套规则1.先看 xmin创建元组的事务是否已提交未提交且非当前事务 → 不可见2.再看 xmax是否有后续事务删除/更新了该元组无操作或仅锁定 → 可见3.交叉比对时序xmax 的更新事务与当前快照的时序关系决定了在「更新已发生但未提交」这类临界场景下的最终可见性这套判定逻辑覆盖了事务隔离级别的核心语义理解它才能真正搞懂 HaishanDB 的并发行为。 #haishanDB #海山数据库 #He3DB
可视化网络拓扑结构)
