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,从而天然消除了可能导致重读问题的可能性。