前言
MVCC，全称 Multi-Version Concurrency Control，即多版本并发控制。它是一种为了提高数据库并发性能而提出的技术，使得在并发读写数据库时，读操作不会阻塞写操作，写操作也不会阻塞读操作。这就解决了传统的锁机制带来的性能瓶颈问题。
MySQL 中，InnoDB 存储引擎 实现了 MVCC。
一、MVCC 要解决的核心问题
在没有 MVCC 的情况下，如果我们要保证事务的隔离性（例如可重复读级别），通常会用锁来实现。当一个事务正在读取某些数据时，其他事务就不能修改这些数据（共享锁），这会导致“读-写”冲突；同样，一个事务在修改数据时（排他锁），其他事务也不能读取，这会导致“写-读”冲突。MVCC 通过创建数据的历史版本来优雅地解决这个问题。
核心思想： 为每行数据维护多个历史版本。当一个事务需要读取数据时，它会看到在它开始之前就已经提交的某个一致性数据快照，而不管当前这些数据被其他事务修改成了什么样子。
二、MVCC 的实现基石
MVCC 的实现依赖于三个核心组件：
- 隐藏字段
- Undo Log
- Read View
下面我们逐一详解。
1. 隐藏字段
InnoDB 为每一行数据（记录）都添加了三个系统隐藏字段：
DB_TRX_ID(6字节)：事务ID。表示最后一次插入或更新该行的事务ID。此外，删除在内部也被视为更新，会在该行数据中设置一个特殊的删除标记。DB_ROLL_PTR(7字节)：回滚指针。指向该行数据的上一个历史版本，存储在 Undo Log 中。DB_ROW_ID(6字节)：行ID。随着新行插入而单调递增的行ID。如果表没有定义主键，InnoDB 会基于这个字段生成一个聚簇索引。
注意： 实际上还有一个删除标记的隐藏字段，用于标记该行是否被删除。
2. Undo Log
Undo Log（回滚日志）主要有两个作用：
- 事务回滚时，用于恢复数据。
- 实现 MVCC 的关键。它存储了数据行的历史版本。
工作原理：
当一个事务对某行数据进行修改（INSERT, UPDATE, DELETE）时：
- UPDATE / DELETE： 会先将该行数据的当前版本（修改前）复制到 Undo Log 中。这个副本中包含了
DB_TRX_ID和DB_ROLL_PTR。新的DB_ROLL_PTR会指向这个刚刚存入 Undo Log 的旧版本。然后才在表中修改该行数据，写入新的DB_TRX_ID和新的DB_ROLL_PTR。 - INSERT： 因为新插入的数据对之前的事务不可见，所以它的 Undo Log 只在事务回滚时需要，在 MVCC 中作用不大。
因此，通过 DB_ROLL_PTR 指针，一行数据的所有历史版本（快照）被串联成一个链表，这个链表就存放在 Undo Log 中。这个链表称为 版本链。链表的头节点是当前的最新记录。
3. Read View（读视图）
Read View 是事务在进行快照读操作时产生的。它定义了当前事务在执行期间，能看到哪些版本的数据。
Read View 主要包含以下几个关键属性：
m_ids：生成 Read View 时，系统中活跃的（未提交的）读写事务的事务ID列表。min_trx_id：m_ids中的最小值。max_trx_id：生成 Read View 时，系统应该分配给下一个事务的ID。（注意：不是m_ids的最大值，而是已创建的最大事务ID+1）。creator_trx_id：创建该 Read View 的事务ID。
三、可见性算法：如何判断一个版本是否可见？
当一个事务执行一条 SELECT 语句（快照读）时，它需要遍历数据行的版本链，并利用自己的 Read View，通过一套算法来决定哪个版本对它来说是可见的。
对于版本链中的某个版本，假设其对应的事务ID为 trx_id，判断规则如下：
- 如果
trx_id == creator_trx_id：
- 说明当前事务自己修改了这行数据，这个版本是可见的。
- 如果
trx_id < min_trx_id：
- 说明这个版本是在当前 Read View 创建之前就已经提交的，这个版本是可见的。
- 如果
trx_id >= max_trx_id：
- 说明这个版本是在当前 Read View 创建之后才开启的事务修改的，这个版本不可见。
- 如果
min_trx_id <= trx_id < max_trx_id：
- 需要检查
trx_id是否在m_ids（活跃事务列表）中：
- 如果在，说明创建 Read View 时，修改这个版本的事务还未提交，该版本不可见。
- 如果不在，说明创建 Read View 时，修改这个版本的事务已经提交了，该版本可见。
四、在不同隔离级别下的表现
MVCC 主要在 READ COMMITTED 和 REPEATABLE READ 这两个隔离级别下工作。
1. REPEATABLE READ（可重复读 - MySQL 默认级别）
- 核心特性： 在同一个事务中，第一次执行快照读时会创建一个 Read View，之后在这个事务中的所有快照读都复用这个相同的 Read View。
- 效果： 因为 Read View 是静态的，所以无论之后其他事务如何提交修改，这个事务看到的数据快照始终和它第一次看到的一样。这就完美实现了“可重复读”。
2. READ COMMITTED（读已提交）
- 核心特性： 在同一个事务中，每次执行快照读都会生成一个新的、独立的 Read View。
- 效果： 因为每次读都会重新获取一次当前系统的活跃事务列表，所以每次都能看到在本次查询开始之前已经提交的所有事务的修改。这就实现了“读已提交”，即能读到其他事务最新提交的内容。
五、总结与流程图
MVCC 工作流程总结：
- 每个数据行都有隐藏的
DB_TRX_ID和DB_ROLL_PTR。 - 修改操作会在 Undo Log 中创建历史版本，形成版本链。
- 事务在快照读时生成 Read View（RC每次生成，RR第一次生成）。
- 通过可见性算法，遍历版本链，找到对当前事务可见的那个数据版本。
判断流程图：
六、补充说明
- 快照读 vs 当前读
- 快照读：普通的
SELECT语句，基于 MVCC 和 Read View 读取历史版本，不加锁。 - 当前读：特殊的
SELECT语句（如SELECT ... FOR UPDATE,SELECT ... LOCK IN SHARE MODE）以及INSERT,UPDATE,DELETE。当前读读取的是记录的最新版本，并且会通过加锁（Next-Key Lock）来保证数据一致性。
- Purge 操作
- 随着时间推移，Undo Log 中旧版本数据会越来越多。系统会有一个后台的 Purge 线程来清理那些不再被任何事务的 Read View 需要的旧版本数据，从而释放存储空间。
