MVCC

MySQL 的 MVCC（Multi-Version Concurrency Control，多版本并发控制） 是一种通过维护数据的多个版本来实现高并发访问的机制，它使得读写操作可以非阻塞地并发执行，同时保证事务的隔离性（如可重复读、读已提交）。以下是 MVCC 的核心原理和实现细节：

## MVCC 解决的问题
在传统锁机制中，读写操作会互相阻塞（如写锁阻塞读锁），导致并发性能下降。
MVCC 通过以下方式优化：
* 读写不互斥：读操作访问历史版本，写操作创建新版本，互不阻塞。
* 避免幻读（在可重复读隔离级别下）：通过一致性视图（Consistent Read View）保证事务内多次读取的数据版本一致。

## MVCC 的核心组件
### 隐藏字段
InnoDB 表中每行数据包含两个隐藏字段：
* DB_TRX_ID：最近修改该行的事务ID（事务开始时分配的唯一递增ID）。
* DB_ROLL_PTR：指向该行旧版本数据的指针（即 Undo Log 的地址）。

### Undo Log（回滚日志）
* 存储数据的历史版本，形成版本链。
* 写入流程：
  * 事务更新某行时，会先将旧数据拷贝到 Undo Log。
  * 新数据写入当前行，并更新 DB_TRX_ID 和 DB_ROLL_PTR。
* 作用：提供数据的历史版本，支持事务回滚和一致性读。

### Read View（一致性视图）
* 定义：事务在某一时刻对数据库的一个逻辑快照，决定该事务能看到哪些版本的数据。
* 关键属性：
  * m_ids：生成 Read View 时活跃（未提交）的事务ID集合。
  * min_trx_id：m_ids 中的最小事务ID。
  * max_trx_id：生成 Read View 时系统将分配的下一个事务ID。
  * creator_trx_id：创建该 Read View 的事务ID（仅写事务需要）。

## MVCC 的可见性规则

事务通过 Read View 判断某行数据是否可见：

* 行数据的 DB_TRX_ID < min_trx_id：该版本已提交，可见。
* 行数据的 DB_TRX_ID ≥ max_trx_id：该版本由未来事务创建，不可见。
* 行数据的 DB_TRX_ID 在 m_ids 中：
  * 若 DB_TRX_ID 仍在活跃事务列表中，不可见。
  * 若 DB_TRX_ID 不在活跃列表中（已提交），可见。
* 行数据的 DB_TRX_ID = creator_trx_id：本事务修改的数据，可见。

若不可见，则沿 Undo Log 版本链回溯旧版本，直到找到符合条件的数据。

## MVCC 在不同隔离级别的行为
(1) 读已提交（Read Committed）
* Read View 生成时机：每次执行查询时生成新的 Read View。
* 结果：每次查询能看到其他事务已提交的最新数据，导致不可重复读。

(2) 可重复读（Repeatable Read）
* Read View 生成时机：仅在事务第一次查询时生成 Read View，后续查询复用该视图。
* 结果：事务内多次读取的数据版本一致，避免不可重复读和幻读（通过一致性快照）。

## MVCC 如何避免幻读？
在可重复读隔离级别下：
* 快照读（普通 SELECT）：基于事务开始时的一致性视图，忽略其他事务的插入/删除操作。
* 当前读（SELECT FOR UPDATE、UPDATE、DELETE）：通过 Next-Key Lock（间隙锁+行锁） 阻止其他事务插入符合条件的新数据。

## MVCC 的优缺点
* 优点
  * 高并发：读写操作互不阻塞，适合读多写少场景。
  * 避免锁竞争：读操作无需加锁，减少死锁概率。
  * 一致性快照：支持可重复读和读已提交的隔离级别。

* 缺点
  * 存储开销：需维护多个数据版本，占用额外磁盘空间（Undo Log）。
  * 历史版本清理：需要定期清理不再使用的 Undo Log（通过 purge 线程）。

## 关键流程总结
* 写操作：生成新版本，更新 DB_TRX_ID 和 DB_ROLL_PTR，旧版本存入 Undo Log。
* 读操作：根据 Read View 判断可见性，沿 Undo Log 版本链查找符合条件的数据。
* 事务提交：新版本数据对其他事务可见（取决于隔离级别）。
* 事务回滚：通过 Undo Log 恢复数据到旧版本。