【MySQL】事务管理

一. 事务的概念

• 事务由一条或多条SQL语句组成，这些语句在逻辑上存在相关性，共同完成一个任务，事务主要用于处理操作量大，复杂度高的数据。比如转账就涉及多条SQL语句，包括查询余额（select）、在当前账户上减去指定金额（update）、在指定账户上加上对应金额（update）等，将这多条SQL语句打包便构成了一个事务。
• MySQL同一时刻可能存在大量事务，如果不对这些事务加以控制，在执行时就可能会出现问题。比如单个事务内部的某些SQL语句执行失败，或是多个事务同时访问同一份数据导致数据不一致的问题。

二. 事务的特征

一个完整的事务，绝对不是简单的 SQL 集合，还需要满足如下四个属性，简称ACID：

• 原子性 (Atomicity)： 事务中的所有操作要么全部完成，要么全部不完成。如果事务中的某个操作失败，整个事务都会回滚，撤销已经完成的操作，使数据库恢复到事务开始前的状态。
• 一致性 (Consistency)： 事务必须确保数据库从一个一致性状态转换到另一个一致性状态。一致性意味着事务执行前后，数据库的完整性约束不能被破坏。
• 隔离性 (Isolation)： 多个事务并发访问同一份数据时，事务之间是相互隔离的，一个事务的执行不能被其他事务干扰。隔离性确保了事务的独立性，防止了事务之间的相互影响导致数据的不一致问题。
• 持久性 (Durability)： 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

事务的存在原因

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

备注：我们后面把 MySQL 中的一行信息，称为一行记录。

三. 事务的版本支持

通过 show engines 命令可以查看数据库引擎：

• Engine：表示存储引擎的名称。
• Support：表示服务器对存储引擎的支持级别，YES表示支持，NO表示不支持，DEFAULT表示数据库默认使用的存储引擎，DISABLED表示支持引擎但已将其禁用。
• Comment：表示存储引擎的简要说明。
• Transactions：表示存储引擎是否支持事务，可以看到InnoDB存储引擎支持事务，而MyISAM存储引擎不支持事务。
• XA：表示存储引擎是否支持XA事务。
• Savepoints：表示存储引擎是否支持保存点。

四. 事务的提交方式

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

查看事务提交方式

show variables like 'autocommit';

用 SET 来改变 MySQL 的自动提交模式

# 设置为禁止自动提交
set autocommit = 0;
show variables like 'autocommit';

# 设置为自动提交
set autocommit = 1;
show variables like 'autocommit';

说明：

• autocommit 的值为 ON 打开自动提交。
• autocommit 的值为 OFF 关闭自动提交，表示手动提交。

五. 事务的常见操作

准备工作

将MySQL的隔离级别设置成读未提交，也就是把隔离级别设置的比较低，方便看到实验现象。

set global transaction isolation level read uncommitted;

需要注意的是，设置全局隔离级别后当前会话的隔离级别不会改变，只会影响后续与 MySQL 新建立的连接，因此需要重启终端才能看到会话的隔离级别被成功设置。

select @@transaction_isolation;

创建测试表

create table account(id int primary key, name varchar(50) not null, balance decimal(10,2) not null
)engine=InnoDB charset=utf8;

演示一：事务的常规操作

启动两个终端，左终端使用begin或start transaction命令启动一个事务，右终端查看银行用户表中的信息。

左终端中的事务向表中插入一条记录，由于我们将隔离级别设置成了读未提交，因此在左终端中的事务使用commit提交之前，在右终端中就能查看到事务向表中插入的记录。

左终端中的事务使用savepoint命令创建一个保存点，然后继续向表中插入一条记录，这时在右终端中也能看到新插入的这条记录。

左终端中的事务使用rollback命令回滚到保存点，这时右终端在查看表中数据时就看不到刚才插入的第二条记录了。

左终端中的事务使用rollback命令回滚到事务最开始，这时右终端在查看表中数据时就看不到任何记录了。

说明：

• 使用 begin 或 start transaction 命令，可以启动一个事务。
• 使用 savepoint 保存点 命令，可以在事务中创建指定名称的保存点。
• 使用 rollback to 保存点 命令，可以让事务回滚到指定保存点。
• 使用 rollback 命令，可以直接让事务回滚到最开始。
• 使用 commit 命令，可以提交事务，提交事务后就不能回滚了。

演示二：原子性

在左终端中启动一个事务，在右终端查看银行用户表中的信息。

左终端中的事务向表中插入一条记录，由于隔离级别是读未提交，因此在右终端中能够查询到插入的这条记录。

如果左终端中的事务在提交之前因为某些原因与MySQL断开连接，那么MySQL会自动让事务回滚到最开始，这时右终端中就看不到之前插入的记录了。

演示三：持久性

在左终端中启动一个事务，在右终端查看银行用户表中的信息。

左终端中的事务向表中插入一条记录，由于隔离级别是读未提交，因此在右终端中能够查询到插入的这条记录。

左终端中的事务在提交后与MySQL断开连接，这时右终端中仍然可以看到之前插入的记录，因为事务提交后数据就被持久化了。

演示四：begin会自动更改提交方式

通过show命令查看autocommit的值为ON，表示事务的提交方式是自动提交，此时银行用户表中有一条记录。

在左终端中启动一个事务并向表中新插入一条记录，由于隔离级别是读未提交，因此在右终端中能够查询到新插入的这条记录。

如果左终端中的事务在提交之前与MySQL断开连接，那么MySQL依旧会自动让事务回滚到最开始，这时右终端中就看不到之前新插入的记录了。

也就是说，使用begin或start transaction命令启动的事务，都必须要使用commit命令手动提交，数据才会被持久化，与是否设置autocommit无关。

演示五：单条SQL与事务的关系

• 实际全局变量autocommit是否被设置影响的是单条SQL语句，InnoDB中的每一条SQL都会默认被封装成事务。
• autocommit为ON，则单条SQL语句执行后会自动被提交，如果为OFF，则SQL语句执行后需要使用commit进行手动提交。

比如通过show命令查看autocommit的值为ON，表示事务的提交方式是自动提交，此时银行用户表中有一条记录。

在左终端中直接向表中新插入一条记录，由于隔离级别是读未提交，因此在右终端中肯定能够查询到新插入的这条记录。

但就算左终端在执行单条SQL后不使用commit进行提交，而直接与MySQL断开连接，这时右终端仍然可以看到之前新插入的记录了，因为单条SQL在执行后被自动提交持久化了。

相反，如果将autocommit设置为OFF，表示事务执行后需要手动提交，此时银行用户表中有两条记录。

在左终端中直接向表中新插入一条记录，由于隔离级别是读未提交，因此在右终端中肯定能够查询到新插入的这条记录。

但如果此时左终端在执行单条SQL后不使用commit进行提交，而直接与MySQL断开连接，那么这时右终端中就看不到之前新插入的记录了，因为这时单条SQL执行后需要使用commit手动提交后才会持久化，在commit之前与MySQL断开连接则会自动进行回滚操作。

也就是说，实际我们之前一直都在使用单SQL事务，只不过autocommit默认是打开的，因此单SQL事务执行后自动就被提交了。

六. 事务的隔离级别

• MySQL服务可能会同时被多个客户端进程（线程）访问，访问的方式以事务的方式进行。
• 一个事务可能由多条SQL语句构成，也就意味着任何一个事务，都有执行前、执行中和执行后三个阶段，而所谓的原子性就是让用户层要么看到执行前，要么看到执行后，执行中如果出现问题，可以随时进行回滚，所以单个事务对用户表现出来的特性就是原子性。
• 但毕竟每个事务都有一个执行的过程，在多个事务各自执行自己的多条SQL时，仍然可能会出现互相影响的情况，比如多个事务同时访问同一张表，甚至是表中的同一条记录。
• 数据库为了保证事务执行过程中尽量不受干扰，于是出现了隔离性的概念，而数据库为了允许事务在执行过程中受到不同程度的干扰，于是出现了隔离级别的概念。

数据库事务的隔离级别有以下四种

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

说明：读写并发时，读存在隔离级别，隔离级别基本上都是通过加锁的方式实现的，不同的隔离级别对锁的使用是不同的，常见的有表锁、行锁、写锁、间隙锁（GAP）、Next-Key锁（GAP+行锁）等。

1. 查看与设置隔离级别

查看会话隔离级别

select @@session.transaction_isolation;# 或者
select @@transaction_isolation;

设置会话隔离级别

set session transaction isolation level read uncommitted;
select @@session.transaction_isolation;

说明：设置会话的隔离级别只会影响当前会话，新起的会话依旧采用全局隔离级。

查看全局隔离级别

select @@global.transaction_isolation;

设置全局隔离级别

set global transaction isolation level read uncommitted;
select @@global.transaction_isolation;

说明：设置全局隔离级别会影响后续的新会话，但当前会话的隔离级别没有发生变化，如果要让当前会话的隔离级别也改变，则需要重启会话。

2. 读未提交 (Read Uncommitted)

读未提交：一个事物读到了另一个事物未提交的数据。

启动两个终端，将隔离级别都设置为读未提交，并查看此时银行用户表中的数据。

在两个终端各自启动一个事务，左终端中的事务所作的修改在没有提交之前，右终端中的事务就已经能够看到了。

• 读未提交是事务的最低隔离级别，几乎没有加锁，虽然效率高，但是问题比较多，所以严重不建议使用。
• 一个事务在执行过程中，读取到另一个执行中的事务所做的修改，但是该事务还没有进行提交，这种现象叫做脏读。

3. 读提交 (Read Committed)

读提交：一个事物读到了另一个事物提交的数据。

启动两个终端，将隔离级别都设置为读提交，并查看此时银行用户表中的数据。

在两个终端各自启动一个事务，左终端中的事务所作的修改在没有提交之前，右终端中的事务无法看到。

只有当左终端中的事务提交后，右终端中的事务才能看到修改后的数据。

不可重复读：事务在执行过程中，多次 select 读取数据时，可能会读取到不同的数据。

4. 可重复读 (Repeatable Read)

可重复读：事务在执行过程中，多次 select 读取数据时，一定会读取到相同的数据。

启动两个终端，将隔离级别都设置为可重复读，并查看此时银行用户表中的数据。

在两个终端各自启动一个事务，左终端中的事务所作的插入、修改、删除在没有提交之前，右终端中的事务无法看到。

并且当左终端中的事务提交后，右终端中的事务仍然看不到插入、修改、删除后的数据。

只有当右终端中的事务提交后再查看表中的数据，这时才能看到修改后的数据。

• 幻读：一个事务在执行过程中，相同的 select 查询得到了新的数据，如同出现了幻觉。
• 存在一些数据库在可重复读隔离级别下，update 数据是满足可重复读的，但 insert 数据会存在幻读问题，因为隔离性是通过对数据加锁完成的，而新插入的数据原本是不存在的，因此一般的加锁无法屏蔽这类问题。

MySQL 通过Next-Key锁 (GAP+行锁) 来解决幻读问题的。

5. 串行化 (Serializable)

串行化：同一时间只有一个事务可以执行。

启动两个终端，将隔离级别都设置为串行化，并查看此时银行用户表中的数据。

在两个终端各自启动一个事务，如果这两个事务都对表进行的是读操作，那么这两个事务可以并发执行，不会被阻塞。

但如果这两个事务中有一个事务要对表进行写操作，那么这个事务就会立即被阻塞。

直到访问这张表的其他事务都提交后，这个被阻塞的事务才会被唤醒，然后才能对表进行修改操作。

• 串行化是事务的最高隔离级别，多个事务同时进行读操作时加的是共享锁，因此可以并发执行读操作，但一旦需要进行写操作，就会进行串行化，效率很低，几乎不会使用。

6. 隔离级别的总结

• 隔离级别越严格，安全性越高，但数据库的并发性能也就越低，在选择隔离级别时往往需要在两者之间找一个平衡点。
• 不可重复读的重点是修改和删除：同样的条件，你读取过的数据,再次读取出来发现值不一样了。
• 幻读的重点在于新增：同样的条件，第1次和第2次读出来的记录数不一样。
• MySQL 默认的隔离级别是可重复读，一般情况下不要修改。

说明：

• 表中只写出了各种隔离级别下进行读操作时是否需要加锁，串行化读时，加的是共享锁 (允许多个事务同时读取同一数据行，但会阻止其他事务对该数据行进行写操作)
• 无论哪种隔离级别，只要需要进行写操作就一定需要加锁。

七. 事务的一致性

事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态，当数据库只包含事务成功提交的结果时，数据库就处于一致性状态。

• 事务在执行过程中如果发生错误，则需要自动回滚到事务最开始的状态，就像这个事务从来没有执行过一样，即一致性需要原子性来保证。
• 事务处理结束后，对数据的修改必须是永久的，即便系统故障也不能丢失，即一致性需要持久性来保证。
• 多个事务同时访问同一份数据时，必须保证这多个事务在并发执行时，不会因为由于交叉执行而导致数据的不一致，即一致性需要隔离性来保证。
• 此外，一致性与用户的业务逻辑强相关，如果用户本身的业务逻辑有问题，最终也会让数据库处于一种不一致的状态。

也就是说，一致性实际是数据库最终要达到的效果，一致性不仅需要原子性、持久性和隔离性来保证，还需要上层用户编写出正确的业务逻辑。

八. 数据库的并发场景

数据库并发场景有三种：

• 读-读并发：不存在任何问题，也不需要并发控制。
• 读-写并发：有线程安全问题，可能会存在事务隔离性问题，可能遇到脏读、不可重复读、幻读。
• 写-写并发：有线程安全问题，可能会存在两类更新丢失问题。

说明：

• 写-写并发场景下的第一类更新丢失又叫做回滚丢失，即一个事务的回滚把另一个已经提交的事务更新的数据覆盖了，第二类更新丢失又叫做覆盖丢失，即一个事务的提交把另一个已经提交的事务更新的数据覆盖了。
• 读-读并发不需要进行并发控制，写-写并发实际也就是对数据进行加锁，这里最值得讨论的是读-写并发，读-写并发是数据库当中最高频的场景，在解决读-写并发时不仅需要考虑线程安全问题，还需要考虑并发的性能问题。

九. 多版本并发控制

• 多版本并发控制 (MVCC) 是一种用来解决读写冲突的无锁并发控制。
• 主要依赖记录中的 三个记录隐藏列字段、undo日志 和 Read View 实现。
• 为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事务ID关联，读操作只读该事务开始前的数据库的快照，通过事务ID 判断事务的先后顺序。
• MVCC保证读写并发时，读操作不会阻塞写操作，写操作也不会阻塞读操作，提高了数据库并发读写的性能，同时还可以解决脏读、幻读和不可重复读等事务隔离性问题。

1. 三个记录隐藏列字段

• DB_TRX_ID (事务ID)：记录修改该行的事务的事务 ID
• DB_ROLL_PTR (回滚指针)：指向该行的回滚记录 (undo log)，回滚记录包含了将行恢复到之前状态所需的信息。
• DB_ROW_ID (行ID)：为每一行分配的一个唯一标识符，当表没有定义聚簇索引时，这个值会被用作内部主键。

说明：

• 采用 InnoDB 存储引擎建立的每张表都会有一个主键，如果用户没有设置，InnoDB 就会自动以 DB_ROW_ID 产生一个聚簇索引。
• 此外，数据库表中的每条记录还有一个删除 flag 隐藏字段，用于表示该条记录是否被删除，便于进行数据回滚。

创建测试表

create table student(name varchar(20) not null, age int not null 
);
insert student values ('张三', 28);
select * from student;

当向表中插入一条记录后，该记录不仅包含name和age字段，还包含三个隐藏字段，如下：

说明：

• 假设插入该记录的事务的事务ID为9，那么该记录的DB_TRX_ID字段填的就是9
• 因为这是插入的第一条记录，所以隐式主键DB_ROW_ID字段填的就是1
• 由于这条记录是新插入的，没有历史版本，所以回滚指针DB_ROLL_PTR的值设置为null

2. undo 日志

MySQL 的三大日志

• redo log：重做日志，用于MySQL崩溃后进行数据恢复，保证数据的持久性。
• bin log：逻辑日志，用于主从数据备份时进行数据同步，保证数据的一致性。
• undo log：回滚日志，用于对已经执行的操作进行回滚，保证事务的原子性。

说明：

• MySQL会为上述三大日志开辟对应的缓冲区，用于存储日志相关的信息，必要时会将缓冲区中的数据刷新到磁盘。
• MVCC的实现主要依赖三大日志中的undo log，记录的历史版本就是存储在undo log对应的缓冲区中的。

模拟 MVCC

现在有一个事务ID为10的事务，要将刚才插入学生表中的记录的学生姓名改为“李四”：

• 因为是要进行写操作，所以需要先给该记录加行锁。
• 修改前，先将该行记录拷贝到undo log中，此时undo log中就有了一行副本数据。
• 然后再将原始记录中的学生姓名改为“李四”，并将该记录的DB_TRX_ID改为10，回滚指针DB_ROLL_PTR设置成undo log中副本数据的地址，从而指向该记录的上一个版本。
• 最后当事务10提交后释放锁，这时最新的记录就是学生姓名为“李四”的那条记录。

修改后的示意图如下：

现在又有一个事务ID为11的事务，要将刚才学生表中的那条记录的学生年龄改为38：

• 因为是要进行写操作，所以需要先给该记录（最新的记录）加行锁。
• 修改前，先将该行记录拷贝到undo log中，此时undo log中就又有了一行副本数据。
• 然后再将原始记录中的学生年龄改为38，并将该记录的DB_TRX_ID改为11，回滚指针DB_ROLL_PTR设置成刚才拷贝到undo log中的副本数据的地址，从而指向该记录的上一个版本。
• 最后当事务11提交后释放锁，这时最新的记录就是学生年龄为38的那条记录。

修改后的示意图如下：

此时我们就有了一个基于链表记录的历史版本链。快照：undo log 中的一个个的历史版本。

说明：

• 所谓的回滚实际就是用 undo log 中的历史数据覆盖当前数据，而所谓的创建保存点就可以理解成是给某些版本做了标记，让我们可以直接用这些版本数据来覆盖当前数据。
• 这种技术实际就是基于版本的写时拷贝，当需要进行写操作时先将最新版本拷贝一份到 undo log 中，然后再进行写操作，和父子进程为了保证独立性而进行的写时拷贝是类似的。

insert和delete的记录如何维护版本链？

• 删除记录并不是真的把数据删除了，而是先将该记录拷贝一份放入 undo log 中，然后将该记录的删除flag隐藏字段设置为1，这样回滚后该记录的删除flag隐藏字段就又变回0了，相当于删除的数据又恢复了。
• 新插入的记录是没有历史版本的，但是一般为了回滚操作，新插入的记录也需要拷贝一份放入 undo log 中，只不过被拷贝到 undo log 中的记录的删除flag隐藏字段被设置为1，这样回滚后就相当于新插入的数据就被删除了。

说明：增加、删除和修改数据都是可以形成版本链的。

当前读 VS 快照读

• 当前读：读取最新的记录，就叫做当前读。
• 快照读：读取历史版本，就叫做快照读。

事务在进行增删查改的时候，并不是都需要进行加锁保护：

• 事务对数据进行增删改的时候，操作的都是最新记录，即当前读，需要进行加锁保护。
• 事务在进行select查询的时候，既可能是当前读也可能是快照读，如果是当前读，那也需要进行加锁保护，但如果是快照读，那就不需要加锁，因为历史版本不会被修改，也就是可以并发执行，提高了效率，这也就是MVCC的意义所在。

而select查询时应该进行当前读还是快照读，则是由隔离级别决定的，在读未提交和串行化隔离级别下，进行当前读，而在读提交和可重复读隔离级别下，进行快照读。

undo log中的版本链何时才会被清除？

• 在undo log中形成的版本链不仅仅是为了进行回滚操作，其他事务在执行过程中也可能读取版本链中的某个版本，也就是快照读。
• 因此，只有当某条记录的最新版本已经修改并提交，并且此时没有其他事务与该记录的历史版本有关了，这时该记录在undo log中的版本链才可以被清除。

说明：

• 对于新插入的记录来说，没有其他事务会访问它的历史版本，因此新插入的记录在提交后就可以将undo log中的版本链清除了。
• 因此版本链在undo log中可能会存在很长时间，尤其是有其他事务和这个版本链相关联的时候，但这也没有坏处，这说明它是一个热数据。

4. Read View

如何保证不同的事务，select 看到哪些内容呢？也就是如何实现隔离级别？由 Read View 决定！

• 当事务在进行快照读操作时会生成Read View (读视图)，他在 MySQL 源码中就是一个类，本质是用来进行可见性判断的。在该事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃的事务ID。
• 当事务创建时，不会创建 Read View，只有事物对某个记录执行快照读的时候，对该记录创建一个Read View，根据这个Read View来判断，当前事务能够看到该记录的哪个版本的数据。

简化的 ReadView 类的源码如下：

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;// ...
};

部分成员说明：

• m_low_limit_id：记录 Read View 生成时刻，系统尚未分配的下一个事务ID
• m_up_limit_id：记录 m_ids 列表中事务ID最小的ID
• m_creator_trx_id：记录创建该 Read View 的事务的事务ID
• m_ids：一张列表，记录 Read View 生成时刻，系统中活跃的事务ID

由于 事务ID (隐藏列DB_TRX_ID) 是单向增长的，因此根据 Read View 中的 m_up_limit_id 和 m_low_limit_id，可以将事务ID分为三个部分：

• 事务ID < m_up_limit_id 的事务：一定是生成 Read View 时已经提交的事务，因为 m_up_limit_id 是生成 Read View 时刻系统中活跃事务ID中的最小ID。已经提交的事务我们应该看到。
• 事务ID >= m_low_limit_id 的事务：一定是生成 Read View 时还没有启动的事务，因为m_low_limit_id是生成Read View时刻，系统尚未分配的下一个事务ID。还未启动的事务我们不应该看到。
• m_up_limit_id <= 事务ID < m_low_limit_id：在生成 Read View 时可能正处于活跃状态，也可能已经提交了。如果事务ID不在m_ids中说明事务已经提交了，我们应该看到，如果事务ID在m_ids中说明事务处于活跃状态，我们不应该看到。

示意图如下：

• 一个事务在进行读操作时，只应该看到 自己提交的事务 或 已经提交的事务 所作的修改，因此我们可以根据 Read View 来判断当前事务能否看到另一个事务所作的修改。
• 版本链中的每个版本的记录都有自己的 DB_TRX_ID，即创建或最近一次修改该记录的事务ID，因此可以依次遍历版本链中的各个版本，通过 Read View 来判断当前事务能否看到这个版本，如果不能则继续遍历下一个版本。

源码策略如下：

bool changes_visible(trx_id_t id, const table_name_t& name) const MY_ATTRIBUTE((warn_unused_result))
{ut_ad(id > 0);//1、事务id小于m_up_limit_id（已提交）或事务id为创建该Read View的事务的id，则可见if (id < m_up_limit_id || id == m_creator_trx_id) {return(true);}check_trx_id_sanity(id, name);//2、事务id大于等于m_low_limit_id（生成Read View时还没有启动的事务），则不可见if (id >= m_low_limit_id) {return(false);}//3、事务id位于m_up_limit_id和m_low_limit_id之间，并且活跃事务id列表为空（即不在活跃列表中），则可见else if (m_ids.empty()) {return(true);}const ids_t::value_type* p = m_ids.data();//4、事务id位于m_up_limit_id和m_low_limit_id之间，如果在活跃事务id列表中则不可见，如果不在则可见return (!std::binary_search(p, p + m_ids.size(), id));
}

说明： 使用该函数时将版本的DB_TRX_ID传给参数id，该函数的作用就是根据Read View，判断当前事务能否看到这个版本。

读提交的整体流程如下

假设当前有条记录：

事务操作：

• 事务4：修改name(张三) 变成name(李四)
• 当 事务2 对某行数据执行了 快照读 ，数据库为该行数据生成一个 Read View 读视图

// 事务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执行快照读前，就提交了事务，此时版本链是：

我们的事务2在快照读该行记录的时候，就会拿该行记录的 DB_TRX_ID 去跟 up_limit_id，low_limit_id 和 m_ids 进行比较，判断当前事务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提交的记录对应的事务ID
DB_TRX_ID=4//比较步骤
DB_TRX_ID（4）< up_limit_id（1） ?  不小于，下一步
DB_TRX_ID（4）>= low_limit_id(5) ? 不大于，下一步
m_ids.contains(DB_TRX_ID) ? 不包含，说明，事务4不在当前的活跃事务中结论：事务4的更改，应该看到

十. 读提交(RC) 与 可重复读(RR) 的本质区别

现象演示一

启动两个终端，将隔离级别都设置为可重复读，并查看此时银行用户表中的数据。

在两个终端各自启动一个事务，在左终端中的事务操作之前，先让右终端中的事务查看一下表中的信息。

左终端中的事务对表中的信息进行修改并提交，右终端中的事务看不到修改后的数据。

在右终端中使用select * from account lock in share mode命令进行当前读，可以看到表中的数据确实是被修改了，只是右终端中的事务看不到而已。

现象演示二

但如果修改一下SQL的执行顺序，在两个终端各自启动一个事务后，直接让左终端中的事务对表中的信息进行修改并提交，然后再让右终端中的事务进行查看，这时右终端中的事务就直接看到了修改后的数据。

右终端中使用select * from account lock in share mode命令进行当前读，可以看到刚才读取到的确实是最新的数据。

• 上面两次实验的唯一区别在于，右终端中的事务在左终端中的事务修改数据之前是否进行过快照读。
• 事务中快照读的结果是非常依赖该事务首次出现快照读 select 的地方，即某个事务中首次出现快照读时，创建了 Read View，决定该事务后续快照读结果的能力。

RR与RC的本质区别

• 正是因为Read View生成时机的不同，从而造成了RC和RR级别下快照读的结果的不同。
• 在RR级别下，事务第一次进行快照读时会创建一个Read View，将当前系统中活跃的事务记录下来，此后再进行快照读时就会直接使用这个Read View进行可见性判断，因此当前事务看不到第一次快照读之后其他事务所作的修改。
• 而在RC级别下，事务每次进行快照读时都会创建一个Read View，然后根据这个Read View进行可见性判断，因此每次快照读时都能读取到被提交了的最新的数据。
• RR级别下快照读只会创建一次Read View，所以RR级别是可重复读的，而RC级别下每次快照读都会创建新的Read View，所以RC级别是不可重复读的。