[面试题] 能详细说一下MVCC机制的执行原理吗？
版块 A：知识讲解 (Knowledge Recap)
MVCC 三个关键组件：
| 组件 | 说明 |
|---|---|
| 隐藏字段 | 每行记录含 DB_TRX_ID（最近修改事务ID）、DB_ROLL_PTR（回滚指针） |
| Undo Log 版本链 | 每次修改旧版本写入 undo log，通过 DB_ROLL_PTR 串联成历史版本链 |
| Read View | 事务读数据时生成的”快照”，记录当前活跃事务ID列表，决定哪个版本可见 |
RC 与 RR 的核心区别（Read View 生成时机）：
| 隔离级别 | Read View 生成时机 | 效果 |
|---|---|---|
| RC | 每次 SELECT 都生成新的 | 能读到已提交的最新数据 |
| RR | 事务内第一次 SELECT 时生成，之后不变 | 同一事务内多次读结果一致 |
版块 B：面试实战 (Combat Script)
Q：能详细说一下 MVCC 机制的执行原理吗？
破局思路：大多数人只能说出”通过 undo log 实现版本控制”。高手的回答会串联起隐藏字段、版本链、Read View 的生成时机，最后落到 RC 和 RR 的实现差异上，这才是面试官真正想听的完整答案。
💬 高手逐字稿
MVCC 这块我来系统讲一下，它本质上是用空间换时间的思路，在不加锁的情况下解决读写并发冲突的。核心逻辑分三层：** 隐藏字段、版本链、Read View。**
第一层，InnoDB 的每一行数据，其实都隐含了两个关键字段：一个是 DB_TRX_ID，记录最近修改这行数据的事务ID；另一个是 DB_ROLL_PTR，是个回滚指针，指向 undo log 里这行数据的上一个历史版本。
第二层，每当有事务对某行数据做 UPDATE 或 DELETE 时，旧的数据不会被直接覆盖，而是被写进 undo log，然后通过 DB_ROLL_PTR 把所有历史版本串起来，形成一条版本链。
第三层，也是最关键的。当一个事务执行快照读（普通 SELECT）时，InnoDB 会生成一个 Read View，里面记录了当前系统里哪些事务是活跃的、还没提交的。读数据时，沿着版本链从最新版本往旧版本遍历，找到第一个在 Read View 看来是可见的版本返回。
这里有个细节是很多人忽略的关键，就是 RC 和 RR 的区别，其实就在于 Read View 的生成时机不同：RC 是每次 SELECT 都生成新的 Read View，所以能读到别人最新提交的数据；RR 是第一次 SELECT 时生成，之后不变，所以保证了整个事务内读一致。