MySQL MVCC 机制详解：解决什么问题？如何实现？
一、MVCC 要解决的核心问题
MySQL 的 MVCC（多版本并发控制） 主要用于解决数据库高并发场景下的两大问题：
1. 读写阻塞问题
- 传统锁机制缺陷：读写操作需互斥锁，导致性能下降（如读阻塞写、写阻塞读）。
- MVCC 方案 ：通过多版本数据实现 读写操作无锁并发，读操作访问历史快照，写操作生成新版本。
2. 事务隔离性问题
- 脏读：读到其他事务未提交的数据。
- 不可重复读：同一事务内多次读取结果不一致。
- 幻读：同一查询条件返回结果集变化。
- MVCC 方案：通过快照读（Snapshot Read）为事务提供一致性视图。
二、MVCC 与事务隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | MVCC 实现方式 |
|---|---|---|---|---|
| READ COMMITTED | 避免 | 不避免 | 不避免 | 每次读生成新快照（最新已提交数据） |
| REPEATABLE READ | 避免 | 避免 | 避免（部分场景需间隙锁） | 事务首次读生成快照，后续复用该快照 |
三、MVCC 实现机制
1. 隐藏字段
每行数据包含三个隐藏字段：
DB_TRX_ID：最近修改该行的事务 ID。DB_ROLL_PTR：指向 undo log 的指针（构成版本链）。DB_ROW_ID：行唯一标识（可选）。
2. Undo Log（回滚日志）
- 存储数据的历史版本，形成版本链。
- 读操作通过版本链访问符合事务可见性的数据版本。
3. Read View（一致性视图）
事务第一次读操作时生成 Read View，包含：
trx_ids：当前活跃事务 ID 集合。min_trx_id：最小活跃事务 ID。max_trx_id：预分配的下一个事务 ID。creator_trx_id：当前事务 ID。
四、数据可见性规则
| 条件 | 是否可见 |
|---|---|
DB_TRX_ID < min_trx_id |
可见（事务已提交） |
DB_TRX_ID > max_trx_id |
不可见（事务在 Read View 后启动） |
min_trx_id ≤ DB_TRX_ID ≤ max_trx_id，且不在 trx_ids 中 |
可见（事务已提交） |
DB_TRX_ID = creator_trx_id |
可见（自身事务修改） |
| 其他情况 | 不可见 |
五、MVCC 的局限性
- 写操作仍需加锁
更新/删除数据时需加行锁或间隙锁保证原子性。 - 历史版本清理
需通过purge线程清理无效的 undo log。 - 幻读的"部分解决"
REPEATABLE READ级别下快照读可避免幻读，但当前读（如SELECT ... FOR UPDATE）需间隙锁。
六、示例场景
java
sql -- 事务 A（事务 ID=100） START TRANSACTION; SELECT * FROM users WHERE id=1; -- 生成 Read View，读到版本 v1
-- 事务 B（事务 ID=200）更新同一行 UPDATE users SET name='Bob' WHERE id=1; -- 创建新版本 v2
-- 事务 A 再次读取 SELECT * FROM users WHERE id=1; -- 根据 Read View 规则，v2 的 DB_TRX_ID=200 > 事务 A 的 Read View 的 max_trx_id，故仍读取 v1总结
MySQL 的 MVCC 通过 多版本 + 快照读 机制，在保证事务隔离性的同时提升并发性能，是 InnoDB 高并发能力的核心设计。开发者需结合事务隔离级别和锁机制，合理规避 MVCC 的局限性。