前言
多版本并发控制（MVCC，Multi-Version Concurrency Control）是数据库实现高并发事务隔离的重要机制，也是 MySQL InnoDB 中提升并发性能的核心手段之一。它通过保存数据的多个历史版本，让读写操作尽量互不阻塞，从而有效避免传统加锁机制带来的性能瓶颈。
1. 核心思想
MVCC 会为每个事务提供一个数据快照（Snapshot），事务读取的是某个时间点上的一致性数据版本，而不是始终读取最新版本。这样做的结果是：
读操作通常无需等待写操作释放锁
写操作一般也不必等待读操作结束
从而实现了非阻塞读，提升数据库并发能力
2. 关键数据结构
InnoDB主要通过Undo Log + 隐藏字段 + Read View来实现MVCC机制。
2.1 Undo Log
Undo Log是 MVCC 实现版本链的基础，也是事务回滚的重要依赖：
插入：
undo log记录主键信息，用于回滚时执行删除删除：先做删除标记，
undo log保存完整行数据，用于后续恢复更新：
undo log保存旧值，并据此形成版本链
2.2 隐藏字段
每行记录都会被自动添加隐藏字段，这些字段对用户不可见，由
InnoDB内部自动维护
| 字段名 | 大小 | 作用 |
|---|---|---|
DB_TRX_ID | 6 字节 | 创建该版本的事务ID（即最后修改这行记录的事务） |
DB_ROLL_PTR | 7 字节 | 回滚指针，指向undo log中的上一个历史版本 |
DB_ROW_ID | 6 字节 | 隐藏主键 |
2.3 Read View
Read View是事务执行快照读时生成的一致性视图，用于决定当前事务能够看到哪些版本的数据。
Read View包含的关键字段：
| 字段 | 说明 |
|---|---|
creator_trx_id | 创建该Read View的事务ID |
m_ids | 生成Read View时，活跃（未提交）事务ID列表 |
min_trx_id | m_ids中的最小值 |
max_trx_id | 生成Read View时，系统将要分配的下一个事务ID（即全局最大值加 1） |
3. 可见性判断规则
当事务读取某一行数据时，会通过比较该行的DB_TRX_ID与Read View中的信息来判断当前版本是否可见：
判断流程（沿版本链从新到旧依次遍历）：1. 如果 DB_TRX_ID == creator_trx_id → 可见（当前事务自己修改的）2. 如果 DB_TRX_ID < min_trx_id → 可见（已提交事务修改的）3. 如果 DB_TRX_ID >= max_trx_id → 不可见（属于将来事务，当前快照生成时尚未发生）4. 如果 min_trx_id <= DB_TRX_ID < max_trx_id： - 如果 DB_TRX_ID 在 m_ids 中 → 不可见（活跃未提交事务修改的） - 如果 DB_TRX_ID 不在 m_ids 中 → 可见（生成快照前已提交的事务修改的）如果当前版本不可见，就沿着 DB_ROLL_PTR 找到上一个版本，继续重复上述判断。
4. 两种读操作
| 读类型 | 说明 | 实现方式 |
|---|---|---|
| 快照读（Snapshot Read） | 不加锁，读取历史版本数据 | 基于 MVCC + Read View |
| 当前读（Current Read） | 读取最新版本，通常需要加锁 | SELECT ... FOR UPDATE/ DML 语句 |
只有普通
SELECT通常属于快照读，其他操作（如UPDATE、DELETE等）一般都是当前读，需要加锁处理
5. 与事务隔离级别的关系
| 隔离级别 | MVCC 行为 |
|---|---|
READ UNCOMMITED | 通常不依赖 MVCC，直接读取最新版本，因此可能产生脏读 |
READ COMMITED | 每次SELECT都会生成新的Read View，因此能看到其他事务已提交的最新修改 |
REPEATABLE READ | 事务开始后生成一个Read View并在整个事务中复用，从而保证可重复读 |
SERIALIZABLE | 通常不使用 MVCC，所有操作都通过加锁串行执行 |
MySQL 默认的事务隔离级别为
REPEATABLE READ
附：RC、RR级别下的InnoDB快照读有什么不同:
1、首先了解mysql的四种隔离级别：
1）未提交读（READ UNCOMMITED），可能出现脏读
2）已提交读（READ COMMITED），简称(RC)，可能出现不可重复读
3）可重复读（REPEATABLE READ），简称（RR）
4）可串行化（SERIALIZABLE）
2、由于Read View生成时机不同，RC、RR级别下快照读的结果也会有所差异:
1)、在 RR 隔离级别下，一个事务对某条记录进行第一次快照读时，会生成一个快照，也就是 Read View，用来记录当前系统中其他仍处于活跃状态的事务。之后再次执行快照读时，复用的仍然是同一个 Read View。也就是说，只要当前事务在其他事务提交更新之前已经执行过快照读，那么之后的快照读都会基于同一份 Read View，因此后续提交的修改对当前事务来说是不可见的。
2)、在RR级别下，快照读生成ReadView时，Read View会记录当时所有其他活跃事务的状态，这些事务产生的修改对当前事务都是不可见的；而早于 Read View 创建并且已经提交的事务所做的修改，则对当前事务可见。
3)、在RC级别下，事务中每一次快照读都会重新生成一个新的快照和Read View，这也是为什么在RC级别的事务里，能够看到其他事务已经提交更新的原因。
