MySQL的Undo Log存储的是逆向操作日志而非数据快照，按事务顺序链式组织在rollback segment中，每条记录含trx_id、roll_ptr及被修改列的旧值或主键值。
Undo Log 存储的是什么结构
MySQL 的 Undo Log 不是简单的时间戳+完整行数据快照，而是以「逆向操作日志」形式存储的逻辑变更记录。每条 INSERT 会生成一条 DELETE 类型的 undo 记录（用于回滚），每条 UPDATE 或 DELETE 则生成一条 INSERT 类型的 undo 记录（用于构建旧版本）。这些记录按事务提交顺序链式组织在 rollback segment 中，每个 undo log record 都携带：trx_id（产生该记录的事务 ID）、roll_ptr（指向上一个 undo 记录的指针）、以及被修改列的实际旧值（或主键值，取决于是否涉及聚簇索引更新）。
Read View 如何决定可见性边界
当一个事务执行一致性读（比如 SELECT 在 RR 或 RC 隔离级别下）时，InnoDB 会创建一个 Read View，其中关键字段包括：m_up_limit_id（活跃事务列表中最小的 trx_id）、m_low_limit_id（当前已分配但未提交的最大 trx_id + 1）、以及 m_ids（生成 Read View 时刻所有活跃事务 ID 的快照数组）。判断某条 undo 记录是否可见，核心规则是：只有当记录的 trx_id 小于 m_up_limit_id，或属于 m_ids 之外且小于 m_low_limit_id 的已提交事务，才对当前事务可见。RC 级别每次查询都新建 Read View；RR 级别只在事务中第一次 SELECT 时创建并复用。
如何从 Undo Log 链上拼出一行历史版本
当 InnoDB 定位到聚簇索引页中某条记录（例如最新版本），发现其 DB_TRX_ID 不满足当前 Read View 可见性时，就顺着该记录头部的 roll_ptr 跳转到对应的 undo log record，提取旧值并覆盖对应字段；若仍不可见，继续跳转——这个过程可能跨越多个 undo log page，形成一条「版本链」。需要注意：
- 不是所有字段都会被重写：undo log 只记录被修改的列，未修改字段沿用上一版本值（所以版本链越深，构造成本越高）
- 如果 undo log 已被 purge 线程清理（例如事务已提交很久，且无长事务依赖该版本），就无法构造出更早版本，此时查询会直接报错或返回空（取决于场景）
-
UPDATE操作若只改非索引列，undo log 中只存旧值；若改主键或唯一索引列，则会额外记录旧主键值，用于定位前镜像
为什么有时查不到“应该存在”的历史数据
常见原因不是逻辑错误，而是生命周期管理问题：
-
innodb_max_purge_lag设置过低，导致 purge 线程激进清理 undo log，使旧版本提前丢失 - 存在未提交的长事务（
TRX_STATE = RUNNING），它持有的 Read View 会让 purge 线程不敢清理其依赖的所有 undo log，但反过来，如果它太久没活动，其他事务的版本链可能因空间压力被截断 - 使用
READ-COMMITTED时误以为能跨语句看到同一事务内不同时间点的数据——其实每次SELECT都新建 Read View，不保证语句间一致性 - 查询条件命中了二级索引，而二级索引记录不含
DB_TRX_ID，需回表后才做可见性判断，此时可能因聚簇索引版本链断裂导致结果异常
真正稳定获取历史版本，得靠 AS OF TIMESTAMP（MySQL 8.0.23+）或手动备份 + binlog 解析，Undo Log 本身只是为 MVCC 服务的临时载体，不是归档机制。
