四个案例看懂 MySQL 事务隔离级别

￡神魔★判官ぃ 2022-09-09 06:52 205阅读 0赞

### 文章目录 ###

*   *  1. 理论
     *  2. SQL 实践
     *   *  2.1 查看隔离级别
         *  2.2 READ UNCOMMITTED
         *   *  2.2.1 准备测试数据
             *  2.2.2 脏读
             *  2.2.3 不可重复读
             *  2.2.4 幻象读
         *  2.3 READ COMMITTED
         *  2.4 REPEATABLE READ
         *  2.5 SERIALIZABLE
     *  3. 总结

很多小伙伴对 MySQL 的隔离级别一直心存疑惑，其实这个问题一点都不难，关键看怎么讲！单纯的看理论，绝对让你晕头转向，但是，如果我们通过几个实际的 SQL 来演示一些，大家就会发现这玩意原来这么简单！

今天松哥想通过几个简单的案例，来和大家演示一下 MySQL 中的事务隔离级别问题。

## 1. 理论 ##

MySQL 中事务的隔离级别一共分为四种，分别如下：

*  序列化（SERIALIZABLE）
 *  可重复读（REPEATABLE READ）
 *  提交读（READ COMMITTED）
 *  未提交读（READ UNCOMMITTED）

四种不同的隔离级别含义分别如下：

1.  SERIALIZABLE

> 如果隔离级别为序列化，则用户之间通过一个接一个顺序地执行当前的事务，这种隔离级别提供了事务之间最大限度的隔离。

1.  REPEATABLE READ

> 在可重复读在这一隔离级别上，事务不会被看成是一个序列。不过，当前正在执行事务的变化仍然不能被外部看到，也就是说，如果用户在另外一个事务中执行同条 SELECT 语句数次，结果总是相同的。（因为正在执行的事务所产生的数据变化不能被外部看到）。

1.  READ COMMITTED

> READ COMMITTED 隔离级别的安全性比 REPEATABLE READ 隔离级别的安全性要差。处于 READ COMMITTED 级别的事务可以看到其他事务对数据的修改。也就是说，在事务处理期间，如果其他事务修改了相应的表，那么同一个事务的多个 SELECT 语句可能返回不同的结果。

1.  READ UNCOMMITTED

> READ UNCOMMITTED 提供了事务之间最小限度的隔离。除了容易产生虚幻的读操作和不能重复的读操作外，处于这个隔离级的事务可以读到其他事务还没有提交的数据，如果这个事务使用其他事务不提交的变化作为计算的基础，然后那些未提交的变化被它们的父事务撤销，这就导致了大量的数据变化。

**在 MySQL 数据库种，默认的事务隔离级别是 REPEATABLE READ**

## 2. SQL 实践 ##

接下来通过几条简单的 SQL 向读者验证上面的理论。

### 2.1 查看隔离级别 ###

通过如下 SQL 可以查看数据库实例默认的全局隔离级别和当前 session 的隔离级别：

MySQL8 之前使用如下命令查看 MySQL 隔离级别：

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

查询结果如图：

![0ac9a933246e7d461fbf83a4582b12e9.png][]

可以看到，默认的隔离级别为 REPEATABLE-READ，全局隔离级别和当前会话隔离级别皆是如此。

**MySQL8 开始，通过如下命令查看 MySQL 默认隔离级别**：

SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;

就是关键字变了，其他都一样。

通过如下命令可以修改隔离级别（建议开发者在修改时修改当前 session 隔离级别即可，不用修改全局的隔离级别）：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

上面这条 SQL 表示将当前 session 的数据库隔离级别设置为 READ UNCOMMITTED，设置成功后，再次查询隔离级别，发现当前 session 的隔离级别已经变了，如图1-2：

![c5365dae0c851cd40b90525cd7f70747.png][]

**注意，如果只是修改了当前 session 的隔离级别，则换一个 session 之后，隔离级别又会恢复到默认的隔离级别，所以我们测试时，修改当前 session 的隔离级别即可。**

### 2.2 READ UNCOMMITTED ###

#### 2.2.1 准备测试数据 ####

READ UNCOMMITTED 是最低隔离级别，这种隔离级别中存在**脏读、不可重复读以及幻象读**问题，所以这里我们先来看这个隔离级别，借此大家可以搞懂这三个问题到底是怎么回事。

下面分别予以介绍。

首先创建一个简单的表，预设两条数据，如下：

![0733120da8f7f12146d42f9c3c9d3467.png][]

表的数据很简单，有 javaboy 和 itboyhub 两个用户，两个人的账户各有 1000 人民币。现在模拟这两个用户之间的一个转账操作。

**注意，如果读者使用的是 Navicat 的话，不同的查询窗口就对应了不同的 session，如果读者使用了 SQLyog 的话，不同查询窗口对应同一个 session，因此如果使用 SQLyog，需要读者再开启一个新的连接，在新的连接中进行查询操作。**

#### 2.2.2 脏读 ####

一个事务读到另外一个事务还没有提交的数据，称之为脏读。具体操作如下：

1.  首先打开两个SQL操作窗口，假设分别为 A 和 B，在 A 窗口中输入如下几条 SQL （输入完成后不用执行）：

START TRANSACTION;
    UPDATE account set balance=balance+100 where name='javaboy';
    UPDATE account set balance=balance-100 where name='itboyhub';
    COMMIT;

1.  在 B 窗口执行如下 SQL，修改默认的事务隔离级别为 READ UNCOMMITTED，如下：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

1.  接下来在 B 窗口中输入如下 SQL，输入完成后，首先执行第一行开启事务（注意只需要执行一行即可）：

START TRANSACTION;
    SELECT * from account;
    COMMIT;

1.  接下来执行 A 窗口中的前两条 SQL，即开启事务，给 javaboy 这个账户添加 100 元。
2.  进入到 B 窗口，执行 B 窗口的第二条查询 SQL（SELECT \* from user;），结果如下：

![8445a580dc44253cbfea98711665c9db.png][]

可以看到，A 窗口中的事务，虽然还未提交，但是 B 窗口中已经可以查询到数据的相关变化了。

这就是**脏读**问题。

#### 2.2.3 不可重复读 ####

不可重复读是指一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。具体操作步骤如下（操作之前先将两个账户的钱都恢复为1000）：

1.  首先打开两个查询窗口 A 和 B ，并且将 B 的数据库事务隔离级别设置为 READ UNCOMMITTED。具体 SQL 参考上文，这里不赘述。
2.  在 B 窗口中输入如下 SQL，然后只执行前两条 SQL 开启事务并查询 javaboy 的账户：

START TRANSACTION;
    SELECT * from account where name='javaboy';
    COMMIT;

前两条 SQL 执行结果如下：

![b04a65d56874d3e4f924437b129c9d84.png][]

1.  在 A 窗口中执行如下 SQL，给 javaboy 这个账户添加 100 块钱，如下：

START TRANSACTION;
    UPDATE account set balance=balance+100 where name='javaboy';
    COMMIT;

4.再次回到 B 窗口，执行 B 窗口的第二条 SQL 查看 javaboy 的账户，结果如下：

![332bfacbc167ccbcdcbb33dfdc847981.png][]

javaboy 的账户已经发生了变化，即前后两次查看 javaboy 账户，结果不一致，这就是**不可重复读**。

**和脏读的区别在于，脏读是看到了其他事务未提交的数据，而不可重复读是看到了其他事务已经提交的数据（由于当前 SQL 也是在事务中，因此有可能并不想看到其他事务已经提交的数据）。**

#### 2.2.4 幻象读 ####

幻象读和不可重复读非常像，看名字就是产生幻觉了。

我举一个简单例子。

在 A 窗口中输入如下 SQL：

START TRANSACTION;
    insert into account(name,balance) values('zhangsan',1000);
    COMMIT;

然后在 B 窗口输入如下 SQL：

START TRANSACTION;
    SELECT * from account;
    delete from account where name='zhangsan';
    COMMIT;

我们执行步骤如下：

1.  首先执行 B 窗口的前两行，开启一个事务，同时查询数据库中的数据，此时查询到的数据只有 javaboy 和 itboyhub。
2.  执行 A 窗口的前两行，向数据库中添加一个名为 zhangsan 的用户，注意不用提交事务。
3.  执行 B 窗口的第二行，由于脏读问题，此时可以查询到 zhangsan 这个用户。
4.  执行 B 窗口的第三行，去删除 name 为 zhangsan 的记录，这个时候删除就会出问题，虽然在 B 窗口中可以查询到 zhangsan，但是这条记录还没有提交，是因为脏读的原因才看到了，所以是没法删除的。此时就产生了幻觉，明明有个 zhangsan，却无法删除。

这就是**幻读**。

看了上面的案例，大家应该明白了**脏读**、**不可重复读**以及**幻读**各自是什么含义了。

### 2.3 READ COMMITTED ###

和 READ UNCOMMITTED 相比，READ COMMITTED 主要解决了脏读的问题，对于不可重复读和幻象读则未解决。

将事务的隔离级别改为 `READ COMMITTED` 之后，重复上面关于脏读案例的测试，发现已经不存在脏读问题了；重复上面关于不可重复读案例的测试，发现不可重复读问题依然存在。

上面那个案例不适用于幻读的测试，我们换一个幻读的测试案例。

还是两个窗口 A 和 B，将 B 窗口的隔离级别改为 `READ COMMITTED`，

然后在 A 窗口输入如下测试 SQL：

START TRANSACTION;
    insert into account(name,balance) values('zhangsan',1000);
    COMMIT;

在 B 窗口输入如下测试 SQL：

START TRANSACTION;
    SELECT * from account;
    insert into account(name,balance) values('zhangsan',1000);
    COMMIT;

测试方式如下：

1.  首先执行 B 窗口的前两行 SQL，开启事务并查询数据，此时查到的只有 javaboy 和 itboyhub 两个用户。
2.  执行 A 窗口的前两行 SQL，插入一条记录，但是并不提交事务。
3.  执行 B 窗口的第二行 SQL，由于现在已经没有了脏读问题，所以此时查不到 A 窗口中添加的数据。
4.  执行 B 窗口的第三行 SQL，由于 name 字段唯一，因此这里会无法插入。此时就产生幻觉了，明明没有 zhangsan 这个用户，却无法插入 zhangsan。

### 2.4 REPEATABLE READ ###

和 READ COMMITTED 相比，REPEATABLE READ 进一步解决了不可重复读的问题，但是幻象读则未解决。

REPEATABLE READ 中关于幻读的测试和上一小节基本一致，不同的是第二步中执行完插入 SQL 后记得提交事务。

由于 REPEATABLE READ 已经解决了不可重复读，因此第二步即使提交了事务，第三步也查不到已经提交的数据，第四步继续插入就会出错。

**注意，REPEATABLE READ 也是 InnoDB 引擎的默认数据库事务隔离级别**

### 2.5 SERIALIZABLE ###

SERIALIZABLE 提供了事务之间最大限度的隔离，在这种隔离级别中，事务一个接一个顺序的执行，不会发生脏读、不可重复读以及幻象读问题，最安全。

如果设置当前事务隔离级别为 SERIALIZABLE，那么此时开启其他事务时，就会阻塞，必须等当前事务提交了，其他事务才能开启成功，因此前面的脏读、不可重复读以及幻象读问题这里都不会发生。

## 3. 总结 ##

总的来说，隔离级别和脏读、不可重复读以及幻象读的对应关系如下：

<table> 
 <thead> 
  <tr> 
   <th align="left">隔离级别</th> 
   <th align="center">脏读</th> 
   <th align="center">不可重复读</th> 
   <th align="center">幻象读</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">READ UNCOMMITTED</td> 
   <td align="center">允许</td> 
   <td align="center">允许</td> 
   <td align="center">允许</td> 
  </tr> 
  <tr> 
   <td align="left">READ COMMITED</td> 
   <td align="center">不允许</td> 
   <td align="center">允许</td> 
   <td align="center">允许</td> 
  </tr> 
  <tr> 
   <td align="left">REPEATABLE READ</td> 
   <td align="center">不允许</td> 
   <td align="center">不允许</td> 
   <td align="center">允许</td> 
  </tr> 
  <tr> 
   <td align="left">SERIALIZABLE</td> 
   <td align="center">不允许</td> 
   <td align="center">不允许</td> 
   <td align="center">不允许</td> 
  </tr> 
 </tbody> 
</table>

性能关系如图：

![bdc4e6e4479ba4a1db01c8488e7a0cab.png][]

好了，这篇文章就和小伙伴们先说这么多，大家不妨写几行 SQL 试一试。

[0ac9a933246e7d461fbf83a4582b12e9.png]: /images/20220829/0ef6923803ce4c399b2b7aab7dffd46e.png
[c5365dae0c851cd40b90525cd7f70747.png]: /images/20220829/9599646469e84e9994bb3f606bf908f7.png
[0733120da8f7f12146d42f9c3c9d3467.png]: /images/20220829/f60de48281c9440986ffacfe7dab19da.png
[8445a580dc44253cbfea98711665c9db.png]: /images/20220829/f0f69ba33fd948509cbc9574b67e2129.png
[b04a65d56874d3e4f924437b129c9d84.png]: /images/20220829/82876a9c408842048eebefaf4893970f.png
[332bfacbc167ccbcdcbb33dfdc847981.png]: /images/20220829/cdb66e4f68934cfebb29f36aa3ad4449.png
[bdc4e6e4479ba4a1db01c8488e7a0cab.png]: /images/20220829/cc2ce3a4a6874ae5a2f4e9c13b8b6e41.png