怎么理解MVCC多版本

MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种数据库并发控制机制，核心思想是：

对同一行数据保留多个历史版本，读写互不阻塞，通过版本判断可见性来实现一致性读。

下面从“为什么需要 → 怎么工作 → 关键组成 → 举例 → 优缺点”来理解。

一、为什么需要 MVCC？

传统并发控制方式的问题：

• 加锁（Locking）：
  • 读阻塞写、写阻塞读
  • 并发性能差
• 读写冲突严重：
  • 长事务查询时，可能被写事务阻塞

MVCC 的目标： ✅ 读不加锁
✅ 读写不冲突
✅ 提高并发性能

二、MVCC 的核心思想

数据不是直接覆盖更新，而是保留多个版本，通过“版本可见性规则”决定当前事务能看到哪个版本。

一句话总结：
更新 = 新增版本；删除 = 标记删除；查询 = 找对自己可见的版本

三、MVCC 在 InnoDB 中是如何实现的？

以 MySQL InnoDB 为例：

1️⃣ 每行记录隐藏字段

InnoDB 给每一行记录加了两个隐藏字段：

实际还有 row_id，但和 MVCC 关系不大

2️⃣ undo log（版本链）

• 每次 UPDATE / DELETE 都会生成 undo log
• undo log 形成一条 版本链

当前行
  ↓
上一个版本（undo）
  ↓
再上一个版本（undo）

事务读数据时，会沿着版本链找“对自己可见”的版本。

3️⃣ Read View（一致性视图）

Read View 是 MVCC 判定的核心

一个 Read View 包含：

• m_ids：当前活跃的事务 ID 列表
• min_trx_id：最小活跃事务 ID
• max_trx_id：下一个将被分配的事务 ID
• creator_trx_id：创建该 Read View 的事务 ID

4️⃣ 可见性判断规则（重点）

对于某条记录版本 trx_id：

if trx_id < min_trx_id
    → 可见（已提交）

else if trx_id >= max_trx_id
    → 不可见（未来事务）

else if trx_id 在 m_ids 中
    → 不可见（未提交）

else
    → 可见

如果不可见，就沿着 undo log 往旧版本找。

四、一个直观例子

初始数据

id = 1, value = 100

事务 A（trx_id = 100，未提交）

UPDATE t SET value = 200 WHERE id = 1;

• 原数据进入 undo log
• 当前行 trx_id = 100

事务 B（trx_id = 101，启动）

SELECT value FROM t WHERE id = 1;

• 创建 Read View
• 发现 trx_id = 100 在活跃事务中
• 不可见
• 从 undo log 中找到旧版本 value = 100
• 返回 100 ✅

✅ 事务 B 读到的不是最新数据，而是历史版本

五、MVCC 解决什么问题？

⚠️ 注意：
MVCC 不能完全解决幻读，InnoDB 在 RR 隔离级别下通过 Next-Key Lock 补充解决。

六、MVCC 的适用场景

✅ 高并发 OLTP
✅ 读多写少
✅ 需要一致性读
✅ 长事务查询

七、MVCC 的代价

• undo log 增多 → 存储压力
• 长事务会导致大量旧版本无法回收
• purge 线程需要清理历史版本

八、一句话总结

MVCC = 数据多版本 + undo log + Read View + 可见性判断
通过“读历史版本”实现 非锁定一致性读，从而提升并发性能。

如果你愿意，我也可以：

• 用 图 画版本链
• 对比 MVCC vs 锁
• 讲 RC 和 RR 下 Read View 的差异