【MySQL】事务管理

我不是女神ヾ 2024-04-27 07:49 3阅读 0赞

#### 文章目录 ####

*  什么是事务
 *  为什么会出现事务
 *  事务的版本支持
 *  事务的提交方式
 *  事务的相关演示
 *  事务的隔离级别
 *   *  查看与设置隔离级别
     *  读未提交（Read Uncommitted）
     *  读提交（Read Committed）
     *  可重复读（Repeatable Read）
     *  串行化（Serializable）
 *  关于一致性
 *  多版本并发控制
 *   *  记录中的3个隐藏字段
     *  undo日志
     *  快照
     *  Read View
 *  RR 与 RC 的本质区别

--------------------

## 什么是事务 ##

**`事务`** 就是一组DML语句组成，这些语句在逻辑上存在相关性，这一组DML语句要么全部成功，要么全部失败，是一个整体。MySQL提供一种机制，保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。事务就是要做的或所做的事情，主要用于处理操作量大，复杂度高的数据，比如转账就涉及多条SQL语句，包括查询余额（select）、在当前账户上减去指定金额（update）、在指定账户上加上对应金额（update）等，将这多条SQL语句打包便构成了一个事务。

MySQL同一时刻可能存在大量事务，如果不对这些事务加以控制，在执行时就可能会出现问题。比如单个事务内部的某些SQL语句执行失败，或是多个事务同时访问同一份数据导致数据不一致的问题。

因此一个完整的事务绝对不是简单的SQL集合，还需要满足如下四个 **`特性`**：

*  **`原子性：`** 一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中如果发生错误，则会自动回滚到事务开始前的状态，就像这个事务从来没有执行过一样。
 *  **`持久性：`** 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
 *  **`隔离性：`** 数据库允许多个事务同时访问同一份数据，隔离性可以保证多个事务在并发执行时 ，不会因为由于交叉执行而导致数据的不一致。
 *  **`一致性：`** 在事务开始之前和事务结束之后，数据库的完整性没有被破坏，这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库的可以自发性地完成预设的工作。

上面的四个属性简称`ACID`：

*  原子性（Atomicity，又称不可分割性）。
 *  一致性（Consistency）。
 *  隔离性（Isolation，又称独立性）。
 *  持久性（Durability）。

其中原子性、隔离性和持久性是手段，一致性是目的。只要原子性、隔离性和持久性能够保证，那么一致性一定能够保证。

--------------------

## 为什么会出现事务 ##

十五被MySQL编写者设计出来，本质是为了当应用程序访问数据库的时候，事务能够简化我们的编程模型，不需要我们去考虑各种各样的潜在错误和并发问题。如果MySQL只是单纯的提供数据存储服务，那么用户在访问数据库时就需要自行考虑各种潜在问题，包括网络异常、服务器宕机等。因此事务本质是为了应用服务的，而不是伴随着数据库系统天生就有的。

--------------------

## 事务的版本支持 ##

MySQL中只有使用了 **`InnoDB`** 数据库引擎的数据库或表才支持事务，**`MyISAM`** 不支持。

![在这里插入图片描述][8da9ac510d3046fbb5bbecc5cf4aed45.png]

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

--------------------

## 事务的提交方式 ##

💕 **查看事务的提交方式**

show variables like 'autocommit';

![在这里插入图片描述][d1301c934a4a414381f2ace4fa93afdf.png]

💕 **设置事务的提交方式**

set autocommit=0/1;

![在这里插入图片描述][8fa2c45f5018421d9128263b64e6270e.png]

--------------------

## 事务的相关演示 ##

💕 **查看隔离级别**

mysql> select @@tx_isolation;
    +-----------------+
    | @@tx_isolation  |
    +-----------------+
    | REPEATABLE-READ | -- 可重复读
    +-----------------+
    1 row in set, 1 warning (0.00 sec)

💕 **设置读未提交的隔离级别**

mysql> set global transaction isolation level READ UNCOMMITTED;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> select @@tx_isolation;
    +-----------------+
    | @@tx_isolation  |
    +-----------------+
    | REPEATABLE-READ |
    +-----------------+
    1 row in set, 1 warning (0.00 sec)

当我们设置完隔离级别后需要重新登录才能生效。

![在这里插入图片描述][cb0b0f4f8dcb49ea94e3dddd0b140d4c.png]

> **准备测试表**

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

![在这里插入图片描述][06eeb02c710d49f4a42bb3e6f84a6455.png]

💕 **事务的开始与回滚**

![在这里插入图片描述][8ee4c6a6da0b460f9e31bbe8491127f3.png]  
![在这里插入图片描述][50a281577fc7448391ba6154810cd724.png]  
![在这里插入图片描述][12aa1e17527441d8b1c875950562e8fe.png]

**说明一下：**

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

💕 **原子性**

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

💕 **持久性**

![在这里插入图片描述][57d5cafda1174206966ce92c479a2bda.png]

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

💕 **begin会自动更改提交方式**

![在这里插入图片描述][887f37fc84074d71a682eb0136c49834.png]

如果左终端中的事务在提交之前与MySQL断开连接，那么MySQL依旧会自动让事务回滚到最开始，这时右终端中就看不到之前新插入的记录了。也就是说，使用begin或start transaction命令启动的事务，都必须要使用commit命令手动提交，数据才会被持久化，与是否设置autocommit无关。

实际全局变量autocommit是否被设置影响的是单条SQL语句，InnoDB中的每一条SQL都会默认被封装成事务。**`autocommit`** 为ON，则单条SQL语句执行后会自动被提交，如果为OFF，则SQL语句执行后需要使用 **`commit`** 进行手动提交。 实际我们之前一直都在使用单SQL事务，只不过autocommit默认是打开的，因此单SQL事务执行后自动就被提交了。

--------------------

## 事务的隔离级别 ##

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

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

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

虽然数据库事务的隔离级别有以上四种，但一个稳态的数据库只会选择这其中的一种，作为自己的默认隔离级别。但数据库默认的隔离级别有时可能并不满足上层的业务需求，因此数据库提供了这四种隔离级别，可以让我们自行设置。隔离级别基本上都是通过加锁的方式实现的，不同的隔离级别对锁的使用是不同的，常见的有表锁、行锁、写锁、间隙锁（GAP）、Next-Key锁（GAP+行锁）等。

--------------------

### 查看与设置隔离级别 ###

> **查看全局隔离级别**

select @@global.tx_isolation;

![在这里插入图片描述][2cc2f8412d664024ac32b40c33170a72.png]

> **查看会话隔离级别**

select @@session.tx_isolation;

![在这里插入图片描述][6f74e28ea7d74fb2aeace71ae3b57a49.png]

此外，通过 `select @@tx_isolation` 命令，也可以查看当前会话的隔离级别。如下：

![在这里插入图片描述][70a4f055baa946138206d6f0c5de0acd.png]

> **设置会话隔离级别**

通过 `set session transaction isolation level 隔离级别`命令，可以设置当前会话的隔离级别。

![在这里插入图片描述][eb9a3ea92ef3489994f1677471c2a73f.png]

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

> **设置全局隔离级别**

通过 `set global transaction isolation level 隔离级别` 命令，可以设置全局隔离级别。

![在这里插入图片描述][9999b8c6b455411d98020f303142d91b.png]

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

--------------------

### 读未提交（Read Uncommitted） ###

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

![在这里插入图片描述][057e04854c914a519b6a1ad365e4fc56.png]

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

![在这里插入图片描述][5dc8d82568eb42b5915201bb72ffb397.png]

`说明一下：`

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

--------------------

### 读提交（Read Committed） ###

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

![在这里插入图片描述][39ff7ea111584758b7d8ffa58ce52b7b.png]

左边的事务所做的修改在没有提交之前，右边终端是无法看到的。

![在这里插入图片描述][ff816f64aa194a32b3477b70ad8d71de.png]

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

![在这里插入图片描述][4ba7ccbfb4cf48939b253869f9ebacbc.png]

一个事务在执行过程中，两个相同的select查询得到了不同的数据，这种现象叫做 **`不可重复读`**。

--------------------

### 可重复读（Repeatable Read） ###

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

![在这里插入图片描述][2a554184c62743de85efe468da6cefb1.png]

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

![在这里插入图片描述][42b9c34245f6459ea43d9666d03e16ff.png]

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

![在这里插入图片描述][d86eb2053f29421eb9d16fd6cfacb929.png]

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

![在这里插入图片描述][a72be241540a4345b8c17b448d5d8dad.png]

`说明一下：`

*  在可重复读隔离级别下，一个事务在执行过程中，相同的select查询得到的是相同的数据，这就是所谓的可重复读。
 *  一般的数据库在可重复读隔离级别下，update数据是满足可重复读的，但insert数据会存在幻读问题，因为隔离性是通过对数据加锁完成的，而新插入的数据原本是不存在的，因此一般的加锁无法屏蔽这类问题。
 *  一个事务在执行过程中，相同的select查询得到了新的数据，如同出现了幻觉，这种现象叫做幻读。
 *  MySQL是通过Next-Key锁（GAP+行锁）来解决幻读问题的。

--------------------

### 串行化（Serializable） ###

启动两个终端，将隔离级别都设置为串行化，并查看此时银行用户表中的数据  
![在这里插入图片描述][cafffafcdd5b4f04acc46bc9f3403a82.png]

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

![在这里插入图片描述][997ff1a1fdb54d25bf889e64ec9ed6e5.png]

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

![在这里插入图片描述][2c1301b2a7f14a469db77fd3f8263674.png]

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

![在这里插入图片描述][b9109018ad614760a188614ee316cf91.png]

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

--------------------

**总结：**

![在这里插入图片描述][ed256ffb6ae74e8aae162cb18c08f338.png]

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

--------------------

## 关于一致性 ##

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

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

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

--------------------

## 多版本并发控制 ##

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

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

说明一下：

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

> **多版本并发控制**

**`多版本并发控制（Multi-Version Concurrency Control，MVCC）`** 是一种用来解决读写冲突的无锁并发控制，主要依赖记录中的 3个隐藏字段、undo日志和Read View 实现。

*  为事务分配单向增长的事务ID，为每个修改保存一个版本，将版本与事务ID相关联，读操作只读该事务开始前的数据库快照。
 *  MVCC保证读写并发时，读操作不会阻塞写操作，写操作也不会阻塞读操作，提高了数据库并发读写的性能，同时还可以解决脏读、幻读和不可重复读等事务隔离性问题。

--------------------

### 记录中的3个隐藏字段 ###

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

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

说明一下：

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

> **示例**

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

![在这里插入图片描述][b6ddd1af6cbe4f05bec8301f21ee272c.png]

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

![在这里插入图片描述][add2d50519e34898b3ae85c47ae61336.png]

*  假设插入该记录的事务的事务ID为9，那么该记录的DB\_TRX\_ID字段填的就是9。
 *  因为这是插入的第一条记录，所以隐式主键DB\_ROW\_ID字段填的就是1。
 *  由于这条记录是新插入的，没有历史版本，所以回滚指针DB\_ROLL\_PTR的值设置为null。
 *  MVCC重点需要的就是这三个隐藏字段，实际还有其他隐藏字段，只不过没有画出。

--------------------

### undo日志 ###

MySQL的三大日志如下：

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

MySQL会为上述三大日志开辟对应的缓冲区，用于存储日志相关的信息，必要时会将缓冲区中的数据刷新到磁盘。

MVCC的实现主要依赖三大日志中的undo log，记录的历史版本就是存储在undo log对应的缓冲区中的。

--------------------

### 快照 ###

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

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

![在这里插入图片描述][7e6aa7a493ef42698037bcf8aa919324.png]

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

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

修改后的示意图如下：

![在这里插入图片描述][4081187a75f74f6e8a5d98659099b9d1.png]

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

说明一下：

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

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

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

> **当前读 VS 快照读**

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

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

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

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

说明一下：

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

--------------------

### Read View ###

事务在进行快照读操作时会生成读视图 **`Read View`**，在该事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃的事务ID。Read View在MySQL源码中就是一个类，本质是用来进行可见性判断的，当事务对某个记录执行快照读的时候，对该记录创建一个Read View，根据这个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;
    	
    	// 省略...
    };

**部分成员说明：**

1.  `m_ids`： 一张列表，记录Read View生成时刻，系统中活跃的事务ID。
2.  `m_up_limit_id`： 记录m\_ids列表中事务ID最小的ID。
3.  `m_low_limit_id`： 记录Read View生成时刻，系统尚未分配的下一个事务ID。
4.  `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比它小的事务在生成Read View时一定已经提交了。
 *  事务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中来判断该事务是否已经提交。

![在这里插入图片描述][4ea2056278784c81996ddfdc264b9522.png]

*  一个事务在进行读操作时，只应该看到自己或已经提交的事务所作的修改，因此我们可以根据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 的本质区别 ##

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

![在这里插入图片描述][1860eba5e8d44c8ea5154263ca443273.png]

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

![在这里插入图片描述][d454870b14fb4cd5971721f8388d9352.png]

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

![在这里插入图片描述][5483b13811f746179d79d619cd8ac99c.png]

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

![在这里插入图片描述][973d303be95e462493f0e8f2ff0b0151.png]

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

![在这里插入图片描述][460781a6715a46679b1663395962eaff.png]

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

![在这里插入图片描述][5a727c40df73490686096711bbf0ee1f.png]

*  上面两次实验的唯一区别在于，右终端中的事务在左终端中的事务修改数据之前是否进行过快照读。
 *  由于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级别是不可重复读的。

--------------------

[8da9ac510d3046fbb5bbecc5cf4aed45.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/87a8e0efa3514e9cb0a6bd5803ed1174.png
[d1301c934a4a414381f2ace4fa93afdf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/6e9763577cec4554a5ef309ac0a4961e.png
[8fa2c45f5018421d9128263b64e6270e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d187574cc1174be5b3c8c88fc8789fe7.png
[cb0b0f4f8dcb49ea94e3dddd0b140d4c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/1df65c896b3c4a49afe9df2e6577aa7e.png
[06eeb02c710d49f4a42bb3e6f84a6455.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/2ba5d2015ec24765a8321c0cc07dd4fd.png
[8ee4c6a6da0b460f9e31bbe8491127f3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/efeb5a80615b4ef28eb18c5569b0f04f.png
[50a281577fc7448391ba6154810cd724.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/f69855046976493d977d25afb4e75cc5.png
[12aa1e17527441d8b1c875950562e8fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/ad15077f8d124f0a8a31fc4bcff3972b.png
[364cc34055d047e0a5aa82ff1db947bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/0e1c9e0e95da4bc18498787098399f28.png
[57d5cafda1174206966ce92c479a2bda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/72b34bedc88c4b5988cb1cb455f666ca.png
[887f37fc84074d71a682eb0136c49834.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/6cd3f18f26bc47aa969ba2fdec2155db.png
[2cc2f8412d664024ac32b40c33170a72.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/87b95d5ddf994b79a3ed57793f9440de.png
[6f74e28ea7d74fb2aeace71ae3b57a49.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/a0d1bcb5f99748beb521dd42e972fc5b.png
[70a4f055baa946138206d6f0c5de0acd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/60b5f00aeb91413d84809d42d140733f.png
[eb9a3ea92ef3489994f1677471c2a73f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/107b20f07658436da8dafdeba23d5e62.png
[9999b8c6b455411d98020f303142d91b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/49c86f7de09e47f79972c1bd59b060a7.png
[057e04854c914a519b6a1ad365e4fc56.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/b1701215ee974851a7ae26d86893263c.png
[5dc8d82568eb42b5915201bb72ffb397.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/803cc7eda9fc45979d37e26c4c17afc6.png
[39ff7ea111584758b7d8ffa58ce52b7b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/4bfde2e66ba845ff9c484e9dfa70cfeb.png
[ff816f64aa194a32b3477b70ad8d71de.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/ff8487fd2158498fb0dde6aa549b124f.png
[4ba7ccbfb4cf48939b253869f9ebacbc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d523877357d44c8bace473e9c8f560fa.png
[2a554184c62743de85efe468da6cefb1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/88521742f3ea4ab094c189818ca52fd6.png
[42b9c34245f6459ea43d9666d03e16ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/3ec5143a5b0140d4a3fe01cb76d7fbee.png
[d86eb2053f29421eb9d16fd6cfacb929.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/1fbc7df4df444f31adb44580fdbd305a.png
[a72be241540a4345b8c17b448d5d8dad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/e7dcb7f57a644a47866943e16b0a1b18.png
[cafffafcdd5b4f04acc46bc9f3403a82.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/5047363c9ceb45dc87f465b22d6ec460.png
[997ff1a1fdb54d25bf889e64ec9ed6e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/e1150180fd4a4b09b8c04cd8d36816d4.png
[2c1301b2a7f14a469db77fd3f8263674.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/8f983e33346f490d800bc8ee09588008.png
[b9109018ad614760a188614ee316cf91.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/6adef0c237ba43dc98e8754b0996fffe.png
[ed256ffb6ae74e8aae162cb18c08f338.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/c972e36ca16e41fa8195bbe224ef394d.png
[b6ddd1af6cbe4f05bec8301f21ee272c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/95651e771f364b96801c6d84757b32c9.png
[add2d50519e34898b3ae85c47ae61336.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/57c4a01cc0854184bc8556c728890c5f.png
[7e6aa7a493ef42698037bcf8aa919324.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d8e3eb74e98e4521a85b21c6df29b142.png
[4081187a75f74f6e8a5d98659099b9d1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/f07f4dc88c5140e6ab88202e017b6925.png
[4ea2056278784c81996ddfdc264b9522.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/40abfe36094f423eb6e248a86b750cdd.png
[1860eba5e8d44c8ea5154263ca443273.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/5563f76eac5448b68f1965f4ffb4973c.png
[d454870b14fb4cd5971721f8388d9352.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/d76beb3766634f8795351061bd7a06d0.png
[5483b13811f746179d79d619cd8ac99c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/40408a2ca9e24e13a573a5f780046698.png
[973d303be95e462493f0e8f2ff0b0151.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/f96af4c7997d4e3b80457979336be755.png
[460781a6715a46679b1663395962eaff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/8a33ae12db514b238352ef37edd53c74.png
[5a727c40df73490686096711bbf0ee1f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/199f6216a91f405ca4492011b853a3f2.png