MySQL Undo Log版本链本质是通过DB_ROLL_PTR隐藏字段串联undo log记录形成的单向追溯链。每行数据含DB_TRX_ID和DB_ROLL_PTR，后者指向更早undo日志，递推至NULL；UPDATE/DELETE写入undo后更新指针，INSERT不加入链；快照读时依Read View沿链遍历找可见版本。
MySQL 中 Undo Log 版本链的串联，本质是 InnoDB 通过两个隐藏字段 + undo log 物理存储，把一行数据的多次修改“串成一条向后追溯的单向链”。它不靠外部索引或额外结构，而是靠每条记录自带的指针和日志内容自然形成。
版本链靠 DB_ROLL_PTR 指针串联
每行数据在 InnoDB 中实际包含两个关键隐藏字段：
-
DB_TRX_ID：标记最近修改该行的事务 ID -
DB_ROLL_PTR：指向该行上一个历史版本在 undo log 中的位置
这个 DB_ROLL_PTR 就是“链条扣”，它始终指向更早的一个 undo log 记录，而那个记录里又存着自己的 DB_ROLL_PTR，如此递推，直到某个版本的指针为 NULL（比如初始插入版本或被 purge 清理前的终点）。
每次 UPDATE/DELETE 都延长一次链
- INSERT 不生成历史版本（无旧数据可回滚），所以不往版本链加节点
- UPDATE 或 DELETE 执行时：
- 先把当前行完整旧值（含隐藏字段）写入 undo log
- 再更新数据页中该行：新值 +
DB_TRX_ID = 当前事务ID+DB_ROLL_PTR = 刚写入的 undo log 地址
- 新版本成为链首，刚写入的 undo log 条目成为链中第二节点，再往前追溯，就是更早的 undo log 条目
例如：
- 初始：
id=1, name="张三"→DB_TRX_ID=0,DB_ROLL_PTR=NULL - 事务 101 改为"李四" → 数据页中变为
(101, "李四", → 指向 undo 中的"张三") - 事务 102 改为"王五" → 数据页中变为
(102, "王五", → 指向 undo 中的"李四")，而那个"李四"记录里又指向"张三"
这样就形成了：最新行（王五） → undo 中的李四 → undo 中的张三
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
Undo log 本身按逻辑链组织
InnoDB 把 undo log 存在回滚段（Rollback Segment）中，每个 undo log 条目都包含：
- 修改前的字段原始值
- 事务 ID（
TRX_ID） - 指向上一个 undo log 条目的
roll_ptr（即物理偏移）
Purge 线程清理时，只删那些确认没有事务需要访问的历史版本，保证正在执行快照读的事务仍能顺着链找到可见版本。
串联不是实时重建，而是查询时动态遍历
当一个事务做普通 SELECT（快照读）时：
- 它拿着自己启动时生成的 Read View（含活跃事务列表、min_trx_id、max_trx_id）
- 从数据页最新版本开始，沿
DB_ROLL_PTR一路回溯 undo log - 对每个版本检查
DB_TRX_ID是否满足可见性规则（比如是否已提交、是否在活跃列表中） - 找到第一个“对该事务可见”的版本，就返回它
所以版本链是静态存储、动态使用的结构——写入时靠指针追加，读取时靠指针遍历。
不复杂但容易忽略
