浅聊MVCC?你学会了吗?

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

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

责任编辑:武晓燕 来源: 码上遇见你
相关推荐

2021-07-01 19:22:33

脚本Shell参数

2023-08-01 12:51:18

WebGPT机器学习模型

2024-01-02 12:05:26

Java并发编程

2022-06-16 07:50:35

数据结构链表

2023-01-31 08:02:18

2023-05-05 06:54:07

MySQL数据查询

2023-08-26 21:34:28

Spring源码自定义

2024-02-02 11:03:11

React数据Ref

2023-10-06 14:49:21

SentinelHystrixtimeout

2022-12-06 07:53:33

MySQL索引B+树

2023-06-26 13:08:52

GraphQL服务数据

2024-03-06 08:28:16

设计模式Java

2022-07-13 08:16:49

RocketMQRPC日志

2023-03-26 22:31:29

2023-07-30 22:29:51

BDDMockitoAssert测试

2024-02-04 00:00:00

Effect数据组件

2024-01-19 08:25:38

死锁Java通信

2023-01-10 08:43:15

定义DDD架构

2023-07-26 13:11:21

ChatGPT平台工具

2022-09-29 08:32:14

查询语句OR
点赞
收藏

51CTO技术栈公众号