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实现的基础,而当前读则是悲观锁实现的基础。
快照读所读取的快照数据来自于何处?换言之,这些快照数据存储在何处?
undo log是 MySQL 中一种重要的事务日志之一。顾名思义,undo log 是用于回滚操作的日志。在事务提交之前,MySQL会将更新前的数据记录到 undo log 日志文件中。当需要回滚事务或者发生数据库崩溃时,可以通过 undo log 进行数据回退。
在这个过程中提到的 "更新前的数据" 存储在undo log中,即我们之前提及的快照。因此,这正是许多人认为 Undo Log 是实现 MVCC 的重要工具的原因之一。
在同一时刻,一条记录可能会被多个事务操作。因此,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 中具有几个重要属性:
每次启动一个事务,都会获得一个递增的事务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进行可见性比较。
另一种情况是,up_limit_id < db_trx_id < low_limit_id。在此情况下,将db_trx_id与Read View中的trx_ids逐一比较。
因此,在读取记录时,经过上述判断,若记录对当前事务可见,则直接返回。若不可见,则需要利用undo log。
当数据的事务ID与Read View规则不符时,需要从undo log中获取数据的历史快照,然后使用数据快照的事务ID与Read View进行可见性比较。如果找到一条快照,则返回数据;否则,返回空。
因此,在InnoDB中,MVCC机制通过Read View和Undo Log相结合来实现。Undo Log保存了历史快照,而Read View则确定了哪一个具体的快照对当前操作是可见的。
根据不同的事务隔离级别,在InnoDB中,获取Read View的时机有所不同。在可重复读隔离级别下,每次查询都会重新获取一次Read View,而在读已提交隔离级别下,只有在事务的第一次查询时获取一次Read View。
因此,在可重复读隔离级别下,由于MVCC机制的存在,能够有效解决不可重复读的问题。因为在可重复读隔离级别中,只在第一次查询时获取一次Read View,从而天然消除了可能导致重读问题的可能性。
我正在参与2024腾讯技术创作特训营最新征文,快来和我瓜分大奖!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。