mvcc由隐藏字段、undo log版本链和read view三大组件协同实现：db_trx_id和db_roll_ptr构成版本链物理基础，undo log存储历史版本，read view控制版本可见性，仅对快照读生效。
MySQL InnoDB 存储引擎的 MVCC 不是靠“魔法”实现的，而是由三个硬性组件协同工作：行记录的隐藏字段、Undo Log 版本链、Read View。缺一不可，且只对快照读（普通 SELECT）生效；当前读（如 SELECT ... FOR UPDATE）仍走加锁路径。
DB_TRX_ID 和 DB_ROLL_PTR 是版本存在的物理基础
每一行数据在 InnoDB 中实际存储时，会自动附加两个隐藏字段：DB_TRX_ID（6 字节）和 DB_ROLL_PTR（7 字节）。前者记录最后一次修改该行的事务 ID，后者是指向 Undo Log 中前一版本的指针。
关键点在于：DB_TRX_ID 不是时间戳，而是单调递增的事务 ID；DB_ROLL_PTR 构成单向链表，把同一行的多个历史版本串起来——这个链表就是“版本链”，头节点是最新值，尾节点是最早插入版本。
- INSERT 操作：直接写入新行，
DB_TRX_ID设为当前事务 ID，DB_ROLL_PTR为空（无旧版本） - UPDATE/DELETE 操作：先将当前行内容拷贝进 Undo Log，再更新原行，
DB_ROLL_PTR指向刚写入的 Undo Log 记录 - DELETE 实际是“逻辑删除”：仅设置删除标记，并保留版本链供快照读回溯
Undo Log 不只是回滚用，更是版本链的存储容器
Undo Log 分为两类：INSERT_UNDO 和 UPDATE_UNDO。只有 UPDATE_UNDO 参与 MVCC —— 它保存的是修改前的完整行镜像，包含当时的 DB_TRX_ID 和上一个 DB_ROLL_PTR 值。
版本链不是存在表空间里，而是分散在 Undo Log 段中；InnoDB 在读取快照时，会顺着 DB_ROLL_PTR 逐跳查找，直到找到满足可见性条件的版本。
- Undo Log 生命周期受事务提交/回滚控制；已提交事务的旧版本不会立刻清理，要等 purge 线程判断是否还有事务需要它
- 如果 long-running 事务长期不提交，会阻塞 purge，导致 Undo Log 膨胀、历史版本堆积
-
innodb_max_purge_lag等参数可调控 purge 压力，但无法绕过可见性依赖
Read View 决定“哪个版本对你可见”
每个事务在首次执行快照读时，会生成一个 Read View，里面固化了当时活跃事务 ID 列表（m_ids）、最小未分配事务 ID（min_trx_id）、最大事务 ID（max_trx_id），以及创建该视图的事务 ID（creator_trx_id）。
判断某版本是否可见的规则是固定的：取该版本的 DB_TRX_ID，对比 Read View 中的边界值。例如在 RR 隔离级别下，只要 DB_TRX_ID 小于 min_trx_id 或不在 m_ids 中，就认为已提交且可见；否则跳到下一个版本继续比。
- RC 隔离级别下，每次
SELECT都新建Read View，所以可能看到其他事务中途提交的新版本 - RR 隔离级别下，只在第一个快照读时创建
Read View，后续读复用它，因此保证“可重复读” - 事务 ID 为 0 的系统版本（如隐式创建的行）或已提交的极老版本，总是可见
真正容易被忽略的是：MVCC 的“多版本”不是无限存档，而是一套带生命周期约束的链式结构；可见性判断发生在引擎层，不经过 SQL 层优化器，也不受索引影响——哪怕走了索引，仍要按版本链逐个检查可见性。这意味着高并发更新+长事务共存时，版本链变长、遍历开销上升，性能拐点可能比预期来得更早。
