前言MVCC，全称 Multi-Version Concurrency Control，即多版本并发控制。它是一种为了提高数据库并发性能而提出的技术，使得在并发读写数据库时，读操作不会阻塞写操作，写操作也不会阻塞读操作。这就解决了传统的锁机制带来的性能瓶颈问题。
MySQL 中，InnoDB 存储引擎 实现了 MVCC。
一、MVCC 要解决的核心问题在没有 MVCC 的情况下，如果我们要保证事务的隔离性（例如可重复读级别），通常会用锁来实现。当一个事务正在读取某些数据时，其他事务就不能修改这些数据（共享锁），这会导致“读-写”冲突；同样，一个事务在修改数据时（排他锁），其他事务也不能读取，这会导致“写-读”冲突。MVCC 通过创建数据的历史版本来优雅地解决这个问题。
核心思想： 为每行数据维护多个历史版本。当一个事务需要读取数据时，它会看到在它开始之前就已经提交的某个一致性数据快照，而不管当前这些数据被其他事务修改成了什么样子。
二、MVCC 的实现基石MVCC 的实现依赖于三个核心组件：
隐藏字段Undo LogRead View下面我们逐一详解。
1. 隐藏字段InnoDB 为每一行数据（记录）都添加了三个系统隐藏字段：
DB_TRX_ID (6字节)：事务ID。表示最后一次插入或更新该行的事务ID。此外，删除在内部也被视为更新，会在该行数据中设置一个特殊的删除标记。DB_ROLL_PTR (7字节)：回滚指针。指向该行数据的上一个历史版本，存储在 Undo Log 中。DB_ROW_ID (6字节)：行ID。随着新行插入而单调递增的行ID。如果表没有定义主键，InnoDB 会基于这个字段生成一个聚簇索引。注意： 实际上还有一个删除标记的隐藏字段，用于标记该行是否被删除。
2. Undo LogUndo 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 需要的旧版本数据，从而释放存储空间。