当前位置：首页 > backend >正文

MySQL——9、事务管理

backend 2025/7/6 8:15:06

事务管理

1、什么是事务？
2、事务常见操作方式
3、事务隔离级别
4、数据库并发场景
- 4.1、读-写
- 4.2、RR与RC的本质区别

1、什么是事务？

mysql是基于CS模式的，是一套网络服务，所以我们是可以在本地连接上远程服务器的mysql服务端的。mysql服务内是多线程并发处理客户端请求的，所以如果CURD不加以控制，会出问题。如下：
在这里插入图片描述
现在有两个mysql客户端，抢票有两个步骤，首先要获取票数判断是否大于0，然后进行update操作让票数减1，现在客户端A获取票数判断完后线程切换，客户端B也获取然后进行判断，这时候两个线程就都进入了if语句内部，所以一张票被卖了两次，这就是线程安全问题。

CURD满足什么属性可以解决上述问题？
1、买票的过程得是原子的。
2、买票互相应该不能影响。
3、买完票应该要永久有效。
4、买前和买后都要是确定的状态。

什么是事务？
事务就是一组DML语句组成，这些语句在逻辑上存在相关性，这一组DML语句要么全部成功，要么全部失败，是一个整体。MySQL提供一种机制，保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。
事务就是要做的或所做的事情，主要用于处理操作量大，复杂度高的数据。假设一种场景：你毕业了，学校的教务系统后台 MySQL 中，不在需要你的数据，要删除你的所有信息(一般不会)，那么要删除你的基本信息(姓名，电话，籍贯等)的同时，也删除和你有关的其他信息，比如：你的各科成绩，你在校表现，甚至你在论坛发过的文章等。这样，就需要多条 MySQL 语句构成，那么所有这些操作合起来，就构成了一个事务。
正如我们上面所说，一个 MySQL 数据库，可不止你一个事务在运行，同一时刻，甚至有大量的请求被包装成事务，在向 MySQL 服务器发起事务处理请求。而每条事务至少一条SQL，最多很多SQL，这样如果大家都访问同样的表数据，在不加保护的情况，就绝对会出现问题。甚至，因为事务由多条SQL构成，那么，也会存在执行到一半出错或者不想再执行的情况，那么已经执行的怎么办呢？
所以，一个完整的事务，绝对不是简单的sql集合，还需要满足如下四个属性：

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（ Read uncommitted ）、读提交（ read committed ）、可重复读（ repeatable read ）和串行化（ Serializable ）
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

上面四个属性，可以简称为 ACID 。
原子性（Atomicity，或称不可分割性）
一致性（Consistency）
隔离性（Isolation，又称独立性）
持久性（Durability）

为什么会出现事务？
事务被MySQL编写者设计出来，本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型，不需要我们去考虑各种各样的潜在错误和并发问题。可以想一下当我们使用事务时，要么提交，要么回滚，我们不会去考虑网络异常了，服务器宕机了，同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的。而不是伴随着数据库系统天生就有的。
备注：我们后面把 MySQL 中的一行信息，称为一行记录。

事务的版本支持：
在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务， MyISAM 不支持。

2、事务常见操作方式

事务的提交方式有两种：自动提交、手动提交。
查看事务提交方式：

show variables like 'autocommit';

在这里插入图片描述
可以看到自动提交默认是打开的。

使用 set 来改变 MySQL 的自动提交模式。

set autocommit=0; # 禁止自动提交
set autocommit=1; # 开启自动提交

为了方便后续演示，将事务隔离级别设置为读未提交。

set global transaction isolation level read uncommitted;

之后重启mysql客户端，使用以下命令进行查看。

select @@transaction_isolation;

在这里插入图片描述

准备工作：创建测试表。

create table if not exists account(id int primary key,name varchar(50) not null default '',balance decimal(10,2) not null default 0.0
)ENGINE=InnoDB;

正常演示-证明事务的开始与回滚
在这里插入图片描述
我们自动提交首先设置为开启。

开始事务有两种方式：

start transaction;
begin;

开启事务后执行sql时，可以设置保存点，方便后续回滚。

savepoint s1;

当我们在左侧插入一条语句后，右边就可以看到插入的语句。
在这里插入图片描述

接着我们再设置两个保存点，然后插入两条数据，右边查询也可以看到新插入的两条数据。
在这里插入图片描述

那么现在我们不想要新插入的王五这条数据了，我们可以使用rollback to进行回滚。
在这里插入图片描述
当我们回滚到s3，右边再次查看的时候久发现王五这条数据已经没有了。
如果说上面的操作我都全部回滚，那么我们可以直接使用rollback命令回滚。

在这里插入图片描述
此时再次查看发现刚才插入的记录都没有了。

非正常演示1-未commit，客户端崩溃，MySQL会自动回滚
在这里插入图片描述
现在我们左侧插入了两条数据，现在我们让左侧的MySQL客户端异常退出，看看会发生什么？
在左侧MySQL客户端直接输入ctrl + \。

可以看到当MySQL异常退出后，MySQL未提交的事务会自动回滚到最初的情况。

非正常演示2-commit之后，客户端崩溃，MySQL数据不会再受到影响，已经持久化。
在这里插入图片描述
当commit之后，数据已经持久化到MySQL中了，这时候客户端崩溃退出，我们查看account表中的数据也是存在的。所以一旦一个事务提交了，就无法回滚了。

我们查看自动提交发现是ON打开的，而这里事务的自动提交跟我们上面的begin开启一个事务是没有关系的，一旦我们begin手动开启了一个事务，就需要手动commit提交，跟是否自动提交无关系。

非正常演示3-验证单条SQL和事务的关系

首先关闭自动提交：
在这里插入图片描述

下面验证关闭自动提交执行单条SQL的效果：
在这里插入图片描述
刚开始有四条数据，我们开启一个事务，删除了id=1的记录并提交。接着我们再直接执行delete语句删除id=3的记录。之后右侧查看发现两条记录都不存在了，然后我们这时候异常退出MySQL客户端，再次查询account，发现id=3的记录恢复了。
这是因为删除id=1的时候，我们开启了一个事务，并且提交了，所以已经持久化到MySQL中了。而后面delete的时候，异常退出了，由于autocommit没有开启，所以进行回滚。

下面看autucommit打开的情况：
在这里插入图片描述
演示了事务和单条sql删除的情况，手动开启事务并提交，即可客户端崩溃也不会回滚，因为已经持久化了。而使用单条sql，由于开启了autocommit，所以执行单条sql就是一个事务，执行完单条sql会自动提交，因此崩溃了再次查看数据也是被删除得了，不会进行回滚。

因此开启了autocommit，执行单条sql就是一个事务，以前执行的单条sql都是事务。

结论：

只要输入begin或者start transaction，事务便必须要通过commit提交，才会持久化，与是否设置set autocommit无关。
事务可以手动回滚，同时，当操作异常，MySQL会自动回滚
对于 InnoDB 每一条 SQL 语言都默认封装成事务，自动提交。（select有特殊情况，因为MySQL有MVCC）
从上面的例子，我们能看到事务本身的原子性(回滚)，持久性(commit)
那么隔离性？一致性？

事务操作注意事项：

如果没有设置保存点，也可以回滚，只能回滚到事务的开始。直接使用rollback(前提是事务还没有提交)
如果一个事务被提交了（commit），则不可以回退（rollback）
可以选择回退到哪个保存点
InnoDB支持事务，MyISAM不支持事务
开始事务可以使用 start transaction 或者 begin

3、事务隔离级别

如何理解隔离性：
MySQL服务可能会同时被多个客户端进程(线程)访问，访问的方式以事务方式进行。一个事务可能由多条SQL构成，也就意味着，任何一个事务，都有执行前，执行中，执行后的阶段。而所谓的原子性，其实就是让用户层，要么看到执行前，要么看到执行后。执行中出现问题，可以随时回滚。所以单个事务，对用户表现出来的特性，就是原子性。
但，毕竟所有事务都要有个执行过程，那么在多个事务各自执行多个SQL的时候，就还是有可能会出现互相影响的情况。比如：多个事务同时访问同一张表，甚至同一行数据。就如同你妈妈给你说：你要么别学，要学就学到最好。至于你怎么学，中间有什么困难，你妈妈不关心。那么你的学习，对你妈妈来讲，就是原子的。那么你学习过程中，很容易受别人干扰，此时，就需要将你的学习隔离开，保证你的学习环境是健康的。

数据库中，为了保证事务执行过程中尽量不受干扰，就有了一个重要特征：隔离性。
数据库中，允许事务受不同程度的干扰，就有了一种重要特征：隔离级别。

隔离级别：

读未提交【Read Uncommitted】：在该隔离级别，所有的事务都可以看到其他事务没有提交的执行结果。（实际生产中不可能使用这种隔离级别的），但是相当于没有任何隔离性，也会有很多并发问题，如脏读，幻读，不可重复读等，我们上面为了做实验方便，用的就是这个隔离性。
读提交【Read Committed】：该隔离级别是大多数数据库的默认的隔离级别（不是 MySQL 默认的）。它满足了隔离的简单定义:一个事务只能看到其他的已经提交的事务所做的改变。这种隔离级别会引起不可重复读，即一个事务执行时，如果多次 select，可能得到不同的结果。
可重复读【Repeatable Read】：这是 MySQL 默认的隔离级别，它确保同一个事务，在执行中，多次读取操作数据时，会看到同样的数据行。但是会有幻读问题。
串行化【Serializable】: 这是事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决了幻读的问题。它在每个读的数据行上面加上共享锁，。但是可能会导致超时和锁竞争（这种隔离级别太极端，实际生产基本不使用）

隔离级别如何实现：隔离，基本都是通过锁实现的，不同的隔离级别，锁的使用是不同的。常见有，表锁，行锁，读锁，写锁，间隙锁(GAP)，Next-Key锁(GAP+行锁)等。不过，我们目前现有这个认识就行，先关注上层使用。

查看和设置隔离性：

# 查看隔离级别
select @@global.transaction_isolation;
select @@session.transaction_isolation;
select @@transaction_isolation;

第一种查看方式是全局配置的，当我们使用mysql客户端连接服务端，会从global全局配置中读取对应的隔离信息，然后将当前会话设置为对应的隔离级别。第二种方式就是从global中读取的，第二种方式和第三种方式本质上是一样的。
设置全局的，当我们重新登录客户端，由于session是从global中获取的，所以每次登录都是global设置的隔离级别，而设置session只对本次登录有效。

# 设置隔离级别
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ
COMMITTED | REPEATABLE READ | SERIALIZABLE}

演示：设置全局隔离级别为串行化，当前隔离级别为读提交。
在这里插入图片描述

读未提交——read uncommitted
在这里插入图片描述
将事务隔离级别设置为读未提交，然后我们启动两个mysql客户端，分别运行两个事务，首先在右边先查看account表的所有信息，发现只有王五，之后左侧事务插入两条数据，并且事务还未提交，右侧再次查看，发现多了刚才插入的两条数据，这就是读未提交。
当一个事务插入数据或者更新数据的时候，该事务还没有提交，另一个并发执行的事务读取可以看到，这就是读未提交。很明显这种方式是有问题的。

该方式几乎没有加锁，虽然效率高，但是问题很多，严重不推荐。
一个事务在执行中，读取到另一个事务的更新(或其他操作)但是未commit的数据，这种现象叫做脏读。

读提交——read committed
在这里插入图片描述
同样启动两个事务，首先右侧查看account表，然后左侧事务进行插入和更新操作但是不commit，然后右侧再次查看，发现并没有读取到左侧事务更新的数据，而当左侧事务commit之后，右侧事务再次查看就可以查到了。这就是读提交。

同时注意到，当左侧事务提交后，右侧事务并没有提交。此时在右侧事务中，在同一个事务中，同样的读取，读取到了不同的值，这种现象叫做不可重复读 not repeatable read。

不可重复读是问题吗？
设想存在这样一张员工表emp，里面包含了员工id、员工姓名、员工薪水。现在年终了，老板需要根据薪资的高低来奖励员工，比如设置了如下的奖励方式：
在这里插入图片描述

现在小张负责处理数据，所以他开启了一个事务，根据薪资水平查找出对应的员工信息。好巧不巧，小王这时候给Tom修改薪资，假设Tom原来薪资是3200，现在修改为4500。当左边事务执行到第三条sql，查询出了tom，而这时候换另一个事务执行，另一个事务执行完并提交。然后继续查询第四条sql，这时候又查出了tom，也就是tom既出现在3000->4000，也出现在4000->5000。
因此不可重复读是有问题的。

可重复读——repeatable read
MySQL默认采用的隔离级别就是可重复读。
在这里插入图片描述
我们重新启动MySQL服务，然后登录查看，发现隔离级别就是可重复读。

下面演示效果：
在这里插入图片描述
启动两个事务，右边先做一次查询，接着左边插入数据后再做一次查询，发现并没有发生变化。左边提交事务后边继续查询，发现还是不变。

在这里插入图片描述
当我们把右边事务提交后再次查询就发现数据变了。

我们发现在左边终端insert数据，在右边终端的事务周期中并没有影响，符合可重复的特点。但是一般的数据库在可重复读情况下，无法屏蔽其他事务insert的数据。因为隔离性实现是对数据加锁完成的，而insert待插入的数据并不存在，那么一般的加锁无法屏蔽这类问题。会造成虽然大部分内容是可重复读的，但是insert的数据在可重复读的情况被读取出来，导致多次查找时会找出新的记录，就如同产生了幻觉，这种现象叫做幻读（phantom read）。而MySQL在RR级别的时候，是解决了幻读问题的。解决方式：Next-Key锁，GAP+行锁解决的。

串行化——serializable
在这里插入图片描述
启动两个事务，左边进行查询，右边也进行查询，发现并没有阻塞，都能正确读取数据。接着左边删除第一条数据，发现直接卡住了。

在这里插入图片描述
左边卡住后，右边查询数据时还是可以看到。而当过了一段时间后，左边timeout超时了。

在这里插入图片描述
另外一种情况，启动两个事务并且分别进行查询数据，然后左侧删除卡住，右边的事务直接提交，提交后发现左边的sql语句也执行了。

在这里插入图片描述
这时候再去查看数据还是不变的，而当左侧事务提交后再查询就发现id=1的数据已被删除。

这时候两个事务执行就是串行化执行的，对所有操作进行加锁，不会有问题，但是效率很低。

在这里插入图片描述
如上图，串行化后执行select直接获取锁然后读取，而进行增删改会放到MySQL的等待队列中。

总结：

其中隔离级别越严格，安全性越高，但数据库的并发性能也就越低，往往需要在两者之间找一个平衡点。
不可重复读的重点是修改和删除：同样的条件，你读取过的数据，再次读取出来发现值不一样了。
幻读的重点在于新增：同样的条件，第1次和第2次读出来的记录数不一样。
说明： mysql 默认的隔离级别是可重复读，一般情况下不要修改。
上面的例子可以看出，事务也有长短事务这样的概念。事务间互相影响，指的是事务在并行执行的时候，即都没有commit的时候，影响会比较大。

在这里插入图片描述

一致性：

事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。当数据库只包含事务成功提交的结果时，数据库处于一致性状态。如果系统运行发生中断，某个事务尚未完成而被迫中断，而该未完成的事务对数据库所做的修改已被写入数据库，此时数据库就处于一种不正确（不一致）的状态。因此一致性是通过原子性来保证的。
其实一致性和用户的业务逻辑强相关，一般MySQL提供技术支持，但是一致性还是要用户业务逻辑做支撑，也就是一致性是由用户决定的。
而技术上，通过AID保证C。

4、数据库并发场景

数据库并发的场景有三种：

读-读：不存在任何问题，也不需要并发控制。
读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读。
写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失(后面补充)

4.1、读-写

多版本并发控制（ MVCC ）是一种用来解决 读-写冲突 的无锁并发控制。
为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事务ID关联，读操作只读该事务开始前的数据库的快照。所以 MVCC 可以为数据库解决以下问题：

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

每个事务都有自己的事务ID，可以根据事务ID的大小来决定事务到来的先后顺序。mysqld可能面临处理多个事务的情况，事务也有生命周期，所以mysqld也要对事务进行管理——先描述，再组织。事务在我们看来就是mysqld中的一个/一套结构体对象。

理解 MVCC 需要知道三个前提知识：3个记录隐藏字段、undo 日志、 Read View
先看隐藏字段，数据库中的表结构有如下隐藏字段：

DB_TRX_ID：6byte，最近修改(修改/插入)事务ID，记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本（简单理解成，指向历史版本就行，这些数据一般在 undo log 中）
DB_ROW_ID：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB 会自动以 DB_ROW_ID 产生一个聚簇索引
补充：实际还有一个删除flag隐藏字段, 即记录被更新或删除并不代表真的删除，而是删除flag标志变了

现在假设我们的测试表结构如下：

create table if not exists student(name varchar(11) not null,age int not null
);insert into student (name, age) values ('张三', 28);

现在我们查表：
在这里插入图片描述
我们发现表中只有两列属性，但实际上不是这样的，实际上表的结构应该如下图

在这里插入图片描述

再来看 undo 日志：
MySQL 将来是以服务进程的方式，在内存中运行。我们之前所讲的所有机制：索引，事务，隔离性，日志等，都是在内存中完成的，即在 MySQL 内部的相关缓冲区(buffer pool)中，保存相关数据，完成各种判断操作。然后在合适的时候，将相关数据刷新到磁盘当中的。而 undo 日志也是在buffer pool中的，我们可以理解为一段内存缓冲区，用来保存日志数据。
接着我们模拟 MVCC :
我们已经在student表中插入的一条数据，所以现在的数据为
在这里插入图片描述
我们假设这次插入的事务ID就是9，接下来有一个事务10，对student表中数据进行update操作，将name从张三改成李四，具体过程如下：

事务10因为要修改，所以要先给该记录加行锁。
修改前，先将该行记录拷贝到undo log中，所以undo log中就有了一行副本数据。(原理就是写时拷贝)
所以现在MySQL中有两行同样的记录。现在修改原始记录中的name，改成 ‘李四’。并且修改原始记录的隐藏字段DB_TRX_ID为当前事务10的ID，我们默认从10开始，之后递增。而原始记录的回滚指针DB_ROLL_PTR列，里面写入undo log中副本数据的地址，从而指向副本记录，表示我的上一个版本就是它。
事务10提交，释放锁。

接着又来一个事务11，也是进行update操作，将age从28改为38，过程如下：

事务11因为也要修改，所以要先给该记录加行锁。
修改前，先将该行记录拷贝到undo log中，所以undo log中就又有了一行副本数据。此时，新的副本，我们采用头插方式，插入undo log。现在修改原始记录中的age，改成38。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前事务11的ID。而原始记录的回滚指针DB_ROLL_PTR列，里面写入undo log中副本数据的地址，从而指向副
本记录，既表示我的上一个版本就是它。
事务11提交，释放锁。

在这里插入图片描述
这样我们就形成了基于链表记录的历史版本链，所谓回滚就是用历史数据覆盖当前数据。
而上面一个一个的版本，我们又称为快照。

一些思考：
1、上面是以更新update讲的，如果是删除delete呢？
不要忘了，还有个隐藏的字段flag，当删除可以把flag字段置为0，而1表示未删除，那么在buffer pool中page中，多行记录就不一定连续了，因为可能中间某行flag置为0表示删除。但是当数据刷盘时，存储到磁盘中数据一定是连续的，这样当恢复的时候读取也是连续的了。那么有了flag字段，删除delete也可以形成版本链。

2、如果是插入insert呢？
insert之前是没有记录的，那么也就无法形成版本链，但是为了保证在不同隔离级别下能否看到数据，所以也需要将insert的数据保存在undo log中。另外还要记录一条相反的delete语句，这样当需要回滚的时候直接执行delete删除即可回滚。当事务commit之后，undo log中的数据就可以删除了。

3、如果是查询select呢？
select并不会修改数据，所以维护select的多个版本没有意义。但是有个问题，select读取的是当前最新版本还是历史的版本呢？
当前读：读取最新的记录就是当前读。增删改都叫做当前读。select也可能当前读，比如select lock in share mode，select for update。
快照读：读取历史版本就叫做快照读。
当多个事务同时增删改的时候，都是当前读所以需要加锁。如果有select过来，并且select也要读取最新版，那么也需要加锁，这就是串行化。但如果select读取的是快照读，这时候就不需要加锁了，可以并行。此时就提高了效率，这就是MVCC存在的意义。那么什么决定select当前读还是快照读？——隔离级别。为什么要有隔离级别？——事务是原子的。事务要经过：begin->CURD->commit，是有一个阶段的，多个事务执行CURD可能会交叉，为了保证事务有先有后，应该让不同事务看到他该看的内容，这就是隔离性和隔离级别解决的问题。

最后来看 Read View:
Read View 就是事务进行快照读操作的时候产生的读视图 (Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID，这个ID是递增的，所以最新的事务，ID值越大)
Read View 在 MySQL 源码中，就是一个类，本质是用来进行可见性判断的。即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件，用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。

下面是Read View结构的一些数据：

class ReadView {
// 省略...
private:/** 高水位，大于等于这个ID的事务均不可见*/trx_id_t m_low_limit_id/** 低水位：小于这个ID的事务均可见 */trx_id_t m_up_limit_id;/** 创建该 Read View 的事务ID*/trx_id_t m_creator_trx_id;/** 创建视图时的活跃事务id列表*/ids_t m_ids;/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/trx_id_t m_low_limit_no;/** 标记视图是否被关闭*/bool m_closed;// 省略...
};

而我们重点关注以下四个字段：
在这里插入图片描述
这里可以解释一下：比如当事务5进行快照读的时候，会产生读视图结构，本质上就是malloc或者new了一个结构体/类，m_dis保存当前活跃的事务，比如有3、4、6。然后up_limit_id就是3了，low_limit_id表示尚未分配的下一个事务ID，假设当前最新的事务ID就是6，那么该值就是7。creator_trx_id就是创建该读视图的id，也就是5。

我们在实际读取数据版本链的时候，是能读取到每一个版本对应的事务ID的，即：当前记录的DB_TRX_ID
那么，我们现在手里面有的东西就有，当前快照读的 ReadView 和版本链中的某一个记录的 DB_TRX_ID
所以现在的问题就是，当前快照读，应不应该读到当前版本记录。
在这里插入图片描述
现在有四个字段：
m_ids：一张列表，用来维护Read View生成时刻，系统正活跃的事务ID
up_limit_id：记录m_ids列表中事务ID最小的ID(没有写错)
low_limit_id：ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1(也没有写错)
creator_trx_id：创建该ReadView的事务ID

如图：最上面是版本链，下方是时间线。
我们先看时间线的最左侧，如果说读视图中的 creator_trx_id 等于 DB_TRX_ID 说明读取的就是我这个事务本身的操作，因此是可以被看到的。如果说隐藏字段的 DB_TRX_ID 小于 up_limit_id 说明这个事务比我当前活跃事务列表里面最小的ID都来的小，也就是在我快照之前就已经提交了，那么也是可以看到的。
接着我们看最右侧，如果说隐藏字段 DB_TRX_ID 大于等于 low_limit_id 说明这个事务ID在我快照创建读视图的时候，还没有分配出来使用，也就是快照之后才启动的事务并且提交，因此不应该被看到。
最后看中间这一块，此时我们需要先解决一个误区，m_ids 集合中存在的活跃事务ID并不一定是连续的，可能先启动的事务晚结束，晚启动的事务由于是短事务所以已经提交了，因此 m_ids 并不一定是连续的事务ID集合。这时候如果 DB_TRX_ID 不在 m_ids 中，说明该事务在读视图创建之前已经提交了，所以可以看到。如果 DB_TRX_ID 在 m_ids 中，说明该事务和当前事务一样，是活跃事务，因此不应该看到。

我们分析完之后再来看一下源码：
在这里插入图片描述
源码的逻辑，首先判断DB_TRX_ID也就是函数中的id，是否小于活跃事务中最小的事务ID，或者等于创建该读视图的事务ID，如果满足说明可以看到返回true。
接着判断id是否大于等于下一个分配事务ID，如果是说明不应该被看到返回false。如果当前活跃事务集合为空，说明当前就只有我一个事务，那么也是可见的。
最后直接返回判断id是否在获取事务id集合m_ids中的逻辑反。如果id在m_ids中返回true，逻辑反之后就是false，表示不可见。如果id不在m_ids中返回false，逻辑反之后就是true，表示可见。

说完理论，我们走一次真实的流程看看：
在这里插入图片描述
当前数据库表记录如图，然后有四个事务并发执行，其中事务4表示将name从张三改为李四，事务4最先提交，接着事务2进行快照读，事务1和3暂时不管，只要知道这三个事务并发执行即可。当事务2快照读会创建读视图，此时读视图中的数据如下：

//事务2的 Read View
m_ids; // 1,3
up_limit_id; // 1
low_limit_id; // 4 + 1 = 5，原因：ReadView生成时刻，系统尚未分配的下一个事务ID
creator_trx_id // 2

在这里插入图片描述

因为事务4先提交，事务2再形成快照读，所以从DB_TRX_ID=4开始找，拿该行记录的DB_TRX_ID去跟
up_limit_id，low_limit_id和活跃事务ID列表(trx_list) 进行比较，判断当前事务2能看到该记录的版本。

在这里插入图片描述
同时我们注意到，事务1、2、3、4刚开始是并发执行的，然后事务4提交后事务2快照读，事务2可以看到事务4提交的数据，因此隔离级别为：读提交。

Read View 是事务可见性的一个类，不是事务创建出来就有 Read View ，而是当这个事务已经存在，首次进行快照读的时候，mysql 形成 Read View

4.2、RR与RC的本质区别

首先设置事务隔离级别为可重复读repeatable read。然后创建如下user表：

create table if not exists user(id int primary key,age int,name varchar(20)
);
insert into user (id, age, name) values (1, 15,'黄蓉');

按照如下方式进行第一次测试：
在这里插入图片描述

首先分别启动左右两个事务A和B，然后分别进行读取user表。接着事务A更新年龄并提交，事务B进行两次查询。我们发现第一次查询的age还是15不变，而第二次查询确是18。这里的select * from user lock in share mode以加共享锁方式进行读取，对应的就是当前读。

接着我们再看第二次测试，步骤如下：
在这里插入图片描述

还是先启动事务A和B，但是事务B什么也不做，事务A进行查询、更新、提交，之后事务B采用快照读和当前读，发现读取到的age都是28。

为什么会这样呢？
当我们执行select的时候，是快照读，进行快照读的时候会创建 Read View ，第一次测试事务B一开始就创建了 Read View ，此时活跃事务集合m_ids里面就有事务A，所以哪怕事务A更新并提交后，后续事务B再进行快照读的时候也读取不到了，因为事务A一直在m_ids里面，此时只有当前读才能看到。
第二次事务B是在事务A提交之后才进行快照读的，当进行快照读才会创建 Read View，此时由于事务A已经提交了，所以对于事务B来说就是旧事务，因此就是可见的。
结论就是：事务中快照读的结果是非常依赖该事务首次出现快照读的地方，即某个事务首次出现快照读决定该事务后续快照读结果的能力。

RR 和 RC 的本质区别：
正是 Read View 生成时机的不同，从而造成RC、RR级别下快照读的结果的不同。在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及 Read View ，将当前系统活跃的其他事务记录起来。此后在调用快照读的时候，还是使用的是同一个 Read View ，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View ，所以对之后的修改不可见。即RR级别下，快照读生成 Read View 时， Read View 会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于 Read View 创建的事务所做的修改均是可见。
而在RC级别下的，事务中，每次快照读都会新生成一个快照和 Read View ，这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。总之在RC隔离级别下，是每个快照读都会生成并获取最新的 Read View。而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View ，之后的快照读获取的都是同一个 Read View 。正是RC每次快照读，都会形成 Read View ，所以RC才会有不可重复读问题。