MySQL事务管理

目录

一、事务概念

二、事务的版本支持

三、事务的提交方式

四、事务的相关演示

4.1 常规操作

4.2 原子性

4.3 持久性

4.4 单条SQL与事务的关系

五、事务的隔离级别 

5.1 查看与设置隔离级别

5.2 读未提交（Read Uncommitted）

5.3 读提交（Read Committed）

5.4 可重复读（Repeatable Read）

5.5 串行化

5.6 隔离级别总结

六、事务的一致性

七、多版本并发控制

7.1 记录中的3个隐藏字段

7.2 日志

7.3 快照

7.4 Read View

八、RR与RC的本质区别

---

一、事务概念

• 事务由一条或多条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存储引擎支持事务
• XA： 表示存储引擎是否支持XA事务
• Savepoints： 表示存储引擎是否支持保存点

三、事务的提交方式

查看事务的提交方式

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

通过show命令查看autocommit全局变量，可以查看事务的自动提交是否被打开（默认打开）

​

注意：autocommit的值为ON表示自动提交打开；值为OFF表示自动提交关闭，即需使用手动提交的方式进行事务的提交

设置自动提交

通过set命令设置autocommit全局变量的值，可以打开或关闭事务的自动提交

​

四、事务的相关演示

准备工作 

为了演示，将MySQL的隔离级别设置成读未提交，易于观察实验现象

设置全局隔离级别后当前会话的隔离级别不会改变，只会影响后续与MySQL新建立的连接，需重启终端才能看到会话的隔离级别改变

创建一个银行用户表，表中包含用户的id、姓名和账户余额

4.1 常规操作

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

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

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

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

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

注意：

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

4.2 原子性

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

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

4.3 持久性

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

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

4.4 单条SQL与事务的关系

• 通过4.2和4.3的实验不难看出，使用begin或start transaction启动的事务，都必须要使用commit命令手动提交，数据才会被持久化，即使设置了autocommit
• 实际全局变量autocommit是否被设置影响的是单条SQL语句，InnoDB中的每一条SQL都会默认被封装成事务
• autocommit为ON，则单条SQL语句执行后会自动被提交，若为OFF，则SQL语句执行后需要使用commit进行手动提交

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

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

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

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

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

但若此时左终端不使用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+行锁）等

5.1 查看与设置隔离级别

查看全局隔离级别

select @@global.tx_isolation

查看会话隔离级别

 通过下面两种方式都可以查看当前会话下的隔离级别

select @@session.tx_isolation;
select @@tx_isolation;

设置会话隔离级别

set session transaction isolation level 隔离级别

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

设置全局隔离级别

set global transaction isolation level 隔离级别

注意：设置全局隔离级别会影响后续的新会话，但当前会话隔离级别不会发生变化，若要让当前会话的隔离级别也改变，则需设置会话隔离级别或重启会话

5.2 读未提交（Read Uncommitted）

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

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

• 读未提交是事务的最低隔离级别，几乎没有加锁，虽然效率高，但是问题比较多，所以严重不建议使用
• 一个事务在执行中，读到另一个执行中事务的更新(或其他操作)但是未commit的数据，这种现象叫做脏读

5.3 读提交（Read Committed）

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

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

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

注意：一个事务在执行过程中，两个相同的select查询得到了不同的数据，这种现象被称为不可重复读

5.4 可重复读（Repeatable Read）

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

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

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

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

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

MySQL解决了可重复读隔离级别下的幻读问题【MySQL通过Next-Key锁（GAP+行锁）来解决幻读问题】，如重新在这两个终端各自启动一个事务，左终端中的事务向表中插入数据的在没有提交前，右终端中的事务无法看到

当左终端中的事务提交后，右终端中的事务仍然看不到新插入的数据

只有当右终端的事务提交后再查看表中的数据，此时才能看到新插入的数据

5.5 串行化

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

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

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

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

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

5.6 隔离级别总结

MySQL中隔离级别： 

• 隔离级别越严格，安全性越高，但数据库的并发性能也就越低，在选择隔离级别时需在两者之间找一个平衡点
• 表中只写出了各种隔离级别下进行读操作时是否需要加锁，因为无论哪种隔离级别，只要需进行写操作就一定要加锁

六、事务的一致性

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

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

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

七、多版本并发控制

数据库的并发场景 

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

注意：

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

多版本并发控制

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

7.1 记录中的3个隐藏字段

数据库表中的每条记录都会有如下3个隐藏字段：

• DB_TRX_ID：6字节，创建或最近一次修改该记录的事务ID
• DB_ROW_ID：6字节，隐含的自增ID（隐藏主键）
• DB_ROLL_PTR：7字节，回滚指针，指向这条记录的上一个版本

注意：

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

示例

创建一个学生表，表中包含学生的姓名和年龄

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

• 假设插入该记录的事务的事务ID为9，那么该记录的DB_TRX_ID字段就是9
• 因为这是插入的第一条记录，所以隐式主键DB_ROW_ID字段就是1
• 由于这条记录是新插入的，没有历史版本，所以回滚指针DB_ROLL_PTR的值设置为null
• MVCC重点需要的就是这三个隐藏字段，实际还有其他隐藏字段，但没有画出

7.2 日志

MySQL三大日志如下：

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

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

7.3 快照

现在有一个事务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中可能会存在很长时间，尤其是有其他事务和这个版本链相关联的时候，但这也没有坏处，这说明其是一个热数据

7.4 Read View

• 事务在进行快照读操作时会生成读视图Read View，在该事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃的事务ID
• Read View在MySQL源码中就是一个类，本质是用来进行可见性判断的，当事务对某个记录执行快照读的时候，对该记录创建一个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;
	
	/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，
	* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/
	trx_id_t m_low_limit_no;
	
	/** 标记视图是否被关闭*/
	bool m_closed;
	
	// 省略...
};

部分成员说明：

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

由于事务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
• 事务ID位于m_up_limit_id和m_low_limit_id之间的事务，在生成Read View时可能正处于活跃状态，也可能已经提交了，这时需通过判断事务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，判断当前事务能否看到这个版本

八、RR与RC的本质区别

现象演示

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

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

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

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

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

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

• 上面两次实验的唯一区别在于，右终端中的事务在左终端中的事务修改数据之前是否进行过快照读
• 由于RR级别下要求事务内每次读取到的结果必须是相同的，因此事务首次进行快照读的地方，决定了该事务后续快照读结果的能力

RR与RC的本质区别

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