MVCC，即多版本并发控制（Multiversion Concurrency Control），类似于数据库锁，是一种优雅的并发控制方案。

我们了解，在数据库环境中，数据操作主要包括读取和写入两种操作，在并发情境下，可能出现以下三种情况：

• 读-读并发
• 读-写并发
• 写-写并发

众所周知，在读取操作时没有写入操作的情况下，并发读取不会引发问题；而写入操作并发时，常常会通过加锁的方式来处理。而针对读取-写入并发的场景，则可通过MVCC机制来解决。

快照读和当前读

要深入了解MVCC机制，其中最关键的一个概念就是快照读。

所谓快照读，即读取快照数据，即在生成快照时刻的数据。比如我们常用的普通SELECT语句在无锁情况下就属于快照读。例如：

SELECT * FROM xx_table WHERE ...

与快照读相对应的另一个概念是当前读，当前读即获取最新的数据。因此，加锁的SELECT操作或进行数据的增删改都属于当前读。例如：

SELECT * FROM xx_table LOCK IN SHARE MODE;

SELECT * FROM xx_table FOR UPDATE;

INSERT INTO xx_table ...

DELETE FROM xx_table ...

UPDATE xx_table ...

可以理解为：快照读是MVCC实现的基础，而当前读则是悲观锁实现的基础。

快照读所读取的快照数据来自于何处？换言之，这些快照数据存储在何处？

UndoLog

undo log是 MySQL 中一种重要的事务日志之一。顾名思义，undo log 是用于回滚操作的日志。在事务提交之前，MySQL会将更新前的数据记录到 undo log 日志文件中。当需要回滚事务或者发生数据库崩溃时，可以通过 undo log 进行数据回退。

在这个过程中提到的 "更新前的数据" 存储在undo log中，即我们之前提及的快照。因此，这正是许多人认为 Undo Log 是实现 MVCC 的重要工具的原因之一。

在同一时刻，一条记录可能会被多个事务操作。因此，undo log 可能会包含一条记录的多个快照。当需要进行快照读取时，就要考虑应该读取哪个快照。这时候就需要利用其他相关信息来做出决定。

行记录的隐式字段

实际上，在数据库的每一行记录中，除了保存我们自定义的字段之外，还包含一些重要的隐式字段：

• db_row_id：隐式主键。如果表没有创建主键，将使用该字段创建聚簇索引。
• db_trx_id：最后一次修改该记录的事务ID。
• db_roll_ptr：回滚指针，指向记录的上一个版本，在本质上指向Undo Log中的前一个版本的快照地址。

由于每次记录更改之前都会先将一个快照存储到undo log中，这些隐式字段也会与记录一起保存在undo log中。因此，每个快照中都包含一个db_trx_id字段，表示最后一次修改该记录的事务ID，以及一个db_roll_ptr字段，指向前一个快照的地址。（db_trx_id和db_roll_ptr是重点，将在后续中用到）

因此，这样就形成了一个快照链表：

有了undo log，又有了几个隐式字段，我们好像还是不知道具体应该读取哪个快照，那怎么办呢？

Read View

此时，Read View 登场，它的主要作用是解决可见性问题，即确定当前事务应该查看哪个快照，而不应查看哪个快照。

在 Read View 中具有几个重要属性：

• trx_ids：系统当前未提交的事务ID列表。
• low_limit_id：应分配给下一个事务的ID值。
• up_limit_id：未提交事务中最小的事务ID。
• creator_trx_id：创建该 Read View 的事务ID。

每次启动一个事务，都会获得一个递增的事务ID。通过ID的大小，我们可以确定事务的时间顺序。

其实原则比较简单，那就是事务ID大的事务应该能看到事务ID小的事务的变更结果，反之则不能！举个例子：

假设当前存在一个事务3想要进行快照读取某条记录，它会首先创建一个Read View，并记录所有当前未提交事务的信息。例如，up_limit_id = 2，low_limit_id = 5，trx_ids= [2,4,5]，creator_trx_id= 3

前文提到，每条记录都包含一个隐式字段db_trx_id，记录对该记录进行最新修改的事务ID，例如db_trx_id = 3；

接下来，数据库将检查此记录的db_trx_id与Read View进行可见性比较。

• 若db_trx_id < up_limit_id，则意味着在Read View中所有未提交事务创建之前，事务ID为3的操作已经提交，并在此期间没有新的提交。因此，对当前事务而言，此记录应该是可见的。
• 若db_trx_id > low_limit_id，则表示事务ID为3的操作是在Read View中所有未提交事务创建之后才提交的，也就是在当前事务开启之后，有其他事务修改了数据并提交。因此，这条记录对当前事务来说是不可见的。（不可见时的处理将在后文讨论）

另一种情况是，up_limit_id < db_trx_id < low_limit_id。在此情况下，将db_trx_id与Read View中的trx_ids逐一比较。

• 若db_trx_id在trx_ids列表中，表示在当前事务开启时，某些未提交事务对数据进行了更改并提交，因此，对当前事务来说，此记录应该是不可见的。
• 若db_trx_id不在trx_ids列表中，表示在当前事务开启之前，其他事务对数据进行了修改并提交，所以对当前事务来说，该记录是可见的。

因此，在读取记录时，经过上述判断，若记录对当前事务可见，则直接返回。若不可见，则需要利用undo log。

当数据的事务ID与Read View规则不符时，需要从undo log中获取数据的历史快照，然后使用数据快照的事务ID与Read View进行可见性比较。如果找到一条快照，则返回数据；否则，返回空。

因此，在InnoDB中，MVCC机制通过Read View和Undo Log相结合来实现。Undo Log保存了历史快照，而Read View则确定了哪一个具体的快照对当前操作是可见的。

MVCC和可重复读

根据不同的事务隔离级别，在InnoDB中，获取Read View的时机有所不同。在可重复读隔离级别下，每次查询都会重新获取一次Read View，而在读已提交隔离级别下，只有在事务的第一次查询时获取一次Read View。

因此，在可重复读隔离级别下，由于MVCC机制的存在，能够有效解决不可重复读的问题。因为在可重复读隔离级别中，只在第一次查询时获取一次Read View，从而天然消除了可能导致重读问题的可能性。

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或微信搜索【码上遇见你】。

免费的Chat GPT可微信搜索【AI贝塔】进行体验，无限使用。

好了，本章节到此告一段落。希望对你有所帮助，祝学习顺利。