MySQL中的MVCC（多版本并发控制）是一种用于提高数据库并发性能的机制，通过维护数据的多个版本，实现读写操作的无锁并发。以下是其核心要点：
1. MVCC的含义
- 全称：Multi-Version Concurrency Control（多版本并发控制）
- 目标：在高并发场景下，避免读写冲突，减少锁竞争，提升性能。
- 适用引擎：InnoDB存储引擎支持，主要用于事务的**读已提交（RC）和可重复读（RR）**隔离级别。
2. MVCC的作用
- 无锁并发：读操作（快照读）无需加锁，写操作按需加锁，减少阻塞。
- 隔离性实现：通过版本控制，实现不同事务隔离级别的数据可见性规则。
- 读已提交（RC）：每次读操作获取最新已提交的数据。
- 可重复读（RR）：事务首次读操作建立一致性快照，后续读操作基于此快照。
- 解决部分幻读：RR级别下，通过快照避免大部分幻读，结合间隙锁彻底解决幻读。
3. MVCC的原理
核心机制
- 隐藏字段：
DB_TRX_ID：记录最后一次修改该行的事务ID。DB_ROLL_PTR：指向Undo Log中旧版本数据的指针。DB_ROW_ID：隐含的行ID（若无主键时自动生成）。
- Undo Log：存储数据的历史版本，用于回滚和版本链追溯。
- Read View：事务执行快照读时生成的一致性视图，决定数据可见性。
Read View的组成
trx_ids：生成Read View时活跃（未提交）的事务ID列表。low_limit_id：当前系统最大事务ID+1。up_limit_id：活跃事务中最小的ID。creator_trx_id：创建该Read View的事务ID。
可见性判断规则
对于某行数据的DB_TRX_ID：
- 如果
DB_TRX_ID < up_limit_id：该版本在Read View创建前已提交，可见。 - 如果
DB_TRX_ID ≥ low_limit_id：该版本在Read View创建后修改，不可见。 - 如果
up_limit_id ≤ DB_TRX_ID < low_limit_id：- 若
DB_TRX_ID在trx_ids中：说明事务未提交，不可见。 - 否则：事务已提交，可见。
- 若
- 对当前事务自身修改的数据，始终可见。
不同隔离级别的行为
- 读已提交（RC）：
- 每次执行SELECT都会生成新的Read View，读取已提交的最新数据。
- 可重复读（RR）：
- 事务首次SELECT时生成Read View，后续操作复用该视图，保证一致性快照。
版本链遍历
- 通过
DB_ROLL_PTR指针访问Undo Log中的旧版本，按规则依次判断可见性。 - 若某个版本对当前事务不可见，则继续回溯更早版本，直到找到可见的版本或到达链头。
4. MVCC的优缺点
- 优点：
- 读操作无锁，减少阻塞，提高并发性能。
- 支持非锁定一致性读，适合读多写少场景。
- 缺点：
- 维护多版本数据增加存储开销（Undo Log）。
- 频繁的版本清理（Purge机制）可能影响性能。
5. 示例场景
- 事务A（RR级别）：
- 开启事务，读取某行数据（生成Read View）。
- 事务B修改该行并提交。
- 事务A再次读取时，由于Read View未更新，仍看到旧版本数据。
- 事务A（RC级别）：
- 开启事务，第一次读取数据。
- 事务B修改并提交后，事务A再次读取会生成新Read View，看到新数据。
总结
MVCC通过维护数据多版本和Read View机制，实现了高效的无锁并发读写，平衡了事务隔离与性能。理解其原理对优化事务设计和排查并发问题至关重要。
