【MySQL】MVCC机制（undo log，read view）

文章目录

前言
[一. 预备知识](#一. 预备知识)
[二. 模拟MVCC](#二. 模拟MVCC)
[三. Read View](#三. Read View)
[四. RC与RR的本质区别](#四. RC与RR的本质区别)
结束语

前言

MVCC（多版本并发控制）是一种用来解决读-写冲突的无锁并发控制

MVCC为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事物ID相关联，读操作只读该事务开始前的数据库的快照，所以MVCC可以解决以下问题

在并发读写数据库数据时，读操作不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写性能
同时解决脏读，幻读，不可重复读 等事务隔离性问题，但不能解决更新丢失问题

数据库并发的场景

数据库并发场景有三种

读-读：不存在任何问题，不需要并发控制，但有使用共享锁
读-写：有线程安全问题，可能会造成事务隔离性问题，如脏读，幻读，不可重复读
写-写：有线程安全问题，可能会存在更新丢失问题，如第一类丢失更新问题和第二类更新丢失问题

补充

第一类更新丢失问题（回滚丢失，Lost update）

第一类更新丢失是指，一个事务被撤销，可能导致其他事务已提交的更新数据被覆盖

时间序号	事务一	事务二
T1	begin开启事务	begin开启事务
T2	查询余额money=1000	查询余额money=1000
T3		存款100，money=1100
T4	取款100，money=900
T5		commit提交事务
T6	回滚取款操作，money恢复1000

正如上述事例，事务一二开始查询余额都是1000，事务二先进行存款操作，并提交。

事务一不知道事务二的存在，进行取款操作，但是又进行了回滚，就会将余额恢复成最开始查询的数额，这就覆盖了事务二的更新操作

第二类更新丢失问题（覆盖丢失/两次更新问题，Second lost update）

第二类更新丢失是指，当两个事物或多个事务查询相同的记录，然后各自基于查询结果更新数据

时间序号	事务一	事务二
T1	begin开启事务	begin开启事务
T2	查询余额money=1000	查询余额money=1000
T3		取款100，money=900
T4		commit提交事务
T5	存款100，money=1100
T6	commit提交事务

事务一二查询相同余额=1000，事务二先进行取款操作，money=900，但事务一后续基于自己的查询结果，进行存款操作，money=1100，这就覆盖了事务二的数据更新

一. 预备知识

学习MVCC前，我们要有以下三个知识了解

3个记录隐藏字段
undo日志（undo log）
Read View

3个记录隐藏字段

这3个字段是记录信息

DB_TRX_ID：6byte。最近修改该记录的事务ID，记录创建这条记录/最后一次修改改记录的事务ID
DB_ROLL_PTR：7byte。回滚指针 ，指向这条记录的上一个版本（指向历史版本，历史版本在undo log中）
DB_ROW_ID：6byte。隐含的自增ID （隐藏主键 ），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

补充：实际还有一个标记删除/更新的flag字段，在事务中删除记录，会将该flag字段标记为删除

比如如下学生表，有name和age两个属性

sql 复制代码

mysql> select * from student;
+--------+-----+
| name   | age |
+--------+-----+
| 张三   |  28 |
+--------+-----+

但其实还有3个隐藏字段

name	age	DB_TRX_ID	DB_ROW_ID	DB_ROLL_PTR
张三	28	最后修改该记录的事务ID	隐式主键 1	回滚指针(指向历史记录)

undo log

MySQL是网络进程服务 ，所有的索引，事务，隔离性，日志等，都是在内存中完成的，即在MySQL内部的相关缓冲区中保存数据，再在合适的时候，进行刷盘，将数据写入磁盘，达到持久化

所以，undo log简单理解，就是MySQL中的一段内存缓冲区，用来保存日志数据

在数据库事务开始之前，MySQL会将记录保存在undo log中，如果事务回滚 或者数据库崩溃 时，可以利用undo log日志中记录的日志信息进行回退。同时也可以提供多版本并发控制下的读（MVCC）

undo log的生命周期

undo log产生 ：在事务开始之前生成
undo log销毁 ：当事务提交之后，undo log并不能马上删除，而是放入待清理的链表，由purge线程判断是否有其他事务在使用undo log保存的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间

注意：undo log也会产生redo log，undo log也需要持久化保护

undo log和redo log的区别

undo log是逻辑日志 ，实现事务的原子性

undo log记录的是事务开始前的数据状态，记录的是更新前的值

undo log实现事务的原子性（提供回滚）

redo log是物理日志 ，实现事务的持久性

redo log记录的是事务完成后的数据状态，记录的是更新后的值

redo log实现事务的持久性（保证数据的完整性）

Read view稍后再讲解，因为需要快照这一概念

二. 模拟MVCC

假设现在有一个事务，其事务ID为10，对student表中记录进行修改update：将name（张三）改成name（李四）

MVCC过程如下：

因为是修改，所以要给该记录加行锁
修改前，先将原本的数据拷贝一份到undo log中，相当于undo log中有一个备份（写时拷贝）
然后，MySQL相当于有两行相同的记录，修改是修改原始记录的name，并且修改原始记录的隐藏字段DB_TRX_ID为修改该数据的事务ID，即10，而该记录的回滚指针DB_ROLL_PTR，里面写入undo log中副本数据的地址，表示上一个版本
事务10提交，释放锁

结果如下图

此时，最新的记录就是name='李四'的那条

接着，又有一个事务11要对student表进行修改（update）：将age(28)改成age(38)

因为是修改，所以需要给该记录加行锁
修改前，拷贝一份原始数据到undo log中
将原始数据的age(28)改成age(38)，并且修改DB_TRX_ID为事务11ID，DB_ROLL_PTR指向undo log中的备份数据地址，表示上一个版本数据

结果如下图

如此就形成了一个基于链表记录的历史版本链。回滚其实就是利用历史数据，覆盖当前数据

上述的一个个版本，被称为一个个快照

update可以形成版本，delete和insert同样也可以。

delete删除数据是设置flag字段为删除，回滚只要再修改flag字段即可
insert插入数据，虽然没有历史版本，但是为了回滚操作，insert的数据也会被放入undo log中，如果当前事务commit提交了，那么undo log的历史insert记录就会被清空

有了undo log，select读取就被分为了两种读：

快照读，读取历史版本

当前读，读取最新数据，select lock in share mode(共享锁)，select for update。增删改也是读取当前数据

当有多个事务同时增删改时，都是当前读，势必需要加锁，此时select如果也是当前读，那就会被阻塞，这就是串行化

但如果是快照读，读取历史版本，则不受加锁限制，可以并发运行，这就是MVCC的意义。

隔离级别决定了select是当前读还是快照读

事务总是有先有后，而事务可以分为三个阶段：执行前，执行中，执行后

隔离性的目的就是让不同的事务看到它该看到的内容

三. Read View

如何实现隔离级别呢？其实就是实现了Read View

Read View是事务进行快照读操作时产生的一个读视图，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID（每个事务开始时，都会被分配到一个ID，此ID是自增的，事务越新，ID值越大）

Read View在MySQL源码中，是一个类。本质是用来进行可见性判断 的。即当我们某个事务执行快照读时，对该记录创建一个Read View读视图，以此判断当前事务能够看到哪个版本的数据，既可能是当前最新数据，也可能是该记录在undo log里的某个历史版本数据

比较关键的属性如下：

cpp 复制代码

class ReadView
{
...
private:
trx_id_t m_low_limit_id;
trx_id_t m_up_limit_id;
trx_id_t m_creator_trx_id;
ids_t m_ids;
bool m_closed;
...
}

m_ids：创建视图时的活跃事务id列表
m_low_limit_id：翻译为高水位，生成ReadView时，系统尚未分配的下一个事务ID ，也就是目前已有的事务ID的最大值+1 ，大于等于这个ID的事务均不可见
m_up_limit_id：翻译为低水位，记录m_ids列表中事务ID的最小ID ，小于这个ID的事务均可见
m_creator_trx_id：创建该读视图的事务ID

我们在实际读取数据版本链的时候，能读取到每一个版本对应的事务ID，也就是隐藏字段DB_TRX_ID

而通过DB_TRX_ID和以上四个属性作比较，就可以判断该记录是否应该被读取到

m_ids列表记录着形成快照的时，活跃的事务ID

如果记录中的DB_TRX_ID，和m_up_limit_id，即m_ids中最小的事务ID 作比较，小于这个事务ID，代表该事务一定已经提交，其记录一定是历史数据 ，可以读取
如果记录中的DB_TRX_ID，等于m_creator_trx_id，代表是自己修改的数据 ，可以读取
如果记录中的DB_TRX_ID，在m_ids中，代表修改该记录的事务还未提交 或在形成快照后才提交 ，不可读取
如果记录中的DB_TRX_ID，大于等于m_low_limit_id，即在快照形成时，系统还未分配的事务ID，代表该数据是在快照形成后才形成 的，不可读取

如果查找不应该看的版本，可以按照回滚指针，跳转到上一个历史版本，直到符合条件

模拟Read View过程

假设当前有记录;

name	age	DB_TRX_ID	DB_ROW_ID	DB_ROLL_PTR
张三	28	null	1	null

目前不关心创建该记录的事务ID，并且因为是创建的记录，所以没有历史版本，所以回滚指针为null

事务操作：

事务1[id=1]	事务2[id=2]	事务3[id=3]	事务4[id=4]
begin	begin	begin	begin
...	...	...	修改且提交
进行中	快照读	进行中
...	...	...

事务4：修改name(张三)变成name(李四)

当事务2对某行数据进行快照读时，数据库会为该行数据生成一个Read View读视图

事务2的Read View

m_ids：1,3

up_limit_id：1

low_limit_id：4+1=5，读视图生成时，系统尚未分配的下一个事务ID

creator_trx_id：2

此时的版本链如下：

因为事务4在事务2形成快照前就提交了，所以是可见的

事务2在快照读时，就会拿该记录的DB_TRX_ID跟Read View中的几个属性比较，判断该版本是否可见

比较步骤

DB_TRX_ID（4）< up_limit_id（1）? 不小于，下一步

DB_TRX_ID（4）>= low_limit_id(5) ? 不大于，下一步

m_ids.contains(DB_TRX_ID) ? 不包含，说明事务4不在当前的活跃事务中。

四. RC与RR的本质区别

RC即Read Committed（读提交），RR即Repeatable Read（可重复读）

详细定义可见【MySQL】事务

Read View生成时机的不同，从而造成RC，RR级别下快照读的结果不同

RR级别的快照读

在RR级别下的某个事务对某条记录的第一次快照读会创建一个快照和Read View，将当前系统活跃的其他事务记录起来

之后再快照读时，还是使用同一个Read View，所以只要当前事务在其他事务提交之前使用过快照读，那么之后的快照读使用的都是同一个Read View，对之后的修改不可见

即在RR界别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的，而早于Read View创建的事务所做的修改均是可见的

RC级别的快照读

在RC级别下，事务没词快照读都会新生成一个快照和Read View，所以即使后来的事务提交了，其修改结果也可见，因为RC级别下的Read View是每次快照读都会新形成的

RC级别下的Read View是每次快照读都会新形成，而RR级别的Read View只会在第一次快照读时形成

结束语

感谢看到此处

如果觉得本篇文章对你有所帮助的话，不妨点个赞支持一下博主，拜托啦，这对我真的很重要。