搞清楚MySQL事务隔离级别

矫情吗；* 2023-06-04 10:53 13阅读 0赞

首先创建一个表 account。创建表的过程略过**（由于 InnoDB 存储引擎支持事务，所以将表的存储引擎设置为 InnoDB）**。表的结构如下：

![1154170-20190905231406355-1110618932.jpg][]

然后往表中插入两条数据，插入后结果如下：

![1154170-20190905231441354-1756581354.jpg][]

为了说明问题，我们打开两个控制台分别进行登录来模拟两个用户（暂且成为用户 A 和用户 B 吧），并设置当前 MySQL 会话的事务隔离级别。

一. read uncommitted（读取未提交数据）

具体**用户 A** 的操作如下：

set session transaction isolation level read uncommitted；
    start transaction;
    select
     * 
    from
     account;

结果如下：

![1154170-20190905231622378-1206867913.jpg][]

用户 B 的操作如下：

set session transaction isolation level read uncommitted;
    start transaction;
    update account 
    set
     account=account+
    200 
    where
     id = 
    1
    ;

随后我们在 A 用户中查询数据，结果如下：

![1154170-20190905231743971-1454978260.jpg][]

#### 结论一 ####

**我们将事务隔离级别设置为 read uncommitted，即便是事务没有 commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种**

#### 那么这么做有什么问题吗？ ####

那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据，这还是比较麻烦的，我们叫**脏读**。我不知道这个名字是怎么起的，为了增强大家的印象，可以这么想，这个事务好轻浮啊，饥渴到连别人没提交的东西都等不及，真脏，呸！

实际上我们的数据改变了吗？

**答案是否定的，数据库里面的数据并没有改变，因为只有事务 commit 后才会更新到数据库。**

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

二. read committed（可以读取其他事务提交的数据）--- 大多数数据库默认的隔离级别

同样的办法，我们将用户 B 所在的会话当前事务隔离级别设置为 read commited。
    
    在用户 A 所在的会话中我们执行下面操作：
    
    update account set account=account-200 where id=1;

![1154170-20190905232035352-1842869615.jpg][]

我们将 id=1 的用户 account 减 200。然后查询，发现 id=1 的用户 account 变为 800。

在 B 用户所在的会话中查询：

1.  `select * from account；`

结果如下：

![1154170-20190905232114350-125423140.jpg][]

我们会发现数据并没有变，还是 1000。

接着在会话 A 中我们将事务提交：

commit;

在会话 B 中查询结果如下：

![1154170-20190905232218357-1032391177.jpg][]

#### 结论二： ####

**当我们将当前会话的隔离级别设置为 read committed 的时候，当前会话只能读取到其他事务提交的数据，未提交的数据读不到。**

#### 那么这么做有什么问题吗？ ####

那就是我们在会话 B 同一个事务中，读取到两次不同的结果。这就造成了不可重复读，**就是两次读取的结果不同。这种现象叫不可重复读。**

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

三. repeatable read（可重读）---MySQL 默认的隔离级别

现在有个需求，就是老板说在同一个事务中查询结果必须保持一致，如果你是数据库，你会怎么做？数据库是这么做的。

在会话 B 中我们当前事务隔离级别为 repeatable read。具体操作如下：

set session transaction isolation level repeatable read;
    start transaction;

接着在会话 B 中查询数据：

![1154170-20190905232522350-402370589.jpg][]

我们在 A 用户所在会话中为表 account 添加一条数据：

insert 
    into
     account(id,account) value(
    3
    ,
    1000
    );
    commit;

然后我们查询看数据插入是否成功：

![1154170-20190905232642349-196621036.jpg][]

回到 B 用户所在的会话，我们查询结果：

![1154170-20190905232735390-1301364922.jpg][]

用户 B 在他所在的会话中想插入一条新数据 id=3，value=1000。来我们操作下：

![1154170-20190905232819359-987389409.jpg][]

#### 什么？竟然插不进去，说我数据重复？ ####

用户 B 当然不服啊，因为查询到数据只有两条啊，为什么插入 id=3 说我数据重复了呢？

我再看一遍，莫非我眼花了？

![1154170-20190905232903445-633179898.jpg][]

试想一下，在实际中用户 A 和用户 B 肯定是相互隔离的，彼此不知道操作什么。用户 B 碰到这种现象，肯定会炸毛的啊，明明不存在的数据，插入却说主键 id=3 数据重复了。

## 结论三： ##

**当我们将当前会话的隔离级别设置为 repeatable read 的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。**

### 有什么问题吗？ ###

管他呢，老板的要求满足了。要一个事务中读取的数据一致（可重复读）。我只能这么做啊，打肿脸装胖子。数据已经发生改变，但是我还是要保持一致。但是，出现了用户 B 面对的问题，**这种现象叫幻读**（记得当时就在这个地方纠结好久，到底什么是幻读啊）。

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

四. serializable（串行化）

同样，我们将用户 B 所在的会话的事务隔离级别设置为 serializable 并开启事务。

set
     session transaction isolation level serializable;
    start transaction;

在用户 B 所在的会话中我们执行下面操作：

select \* from account;

结果如下：

![1154170-20190905233236358-2123694351.jpg][]

那我们这个时候在用户 A 所在的会话中写数据呢？

![1154170-20190905233324355-1087698134.jpg][]

我们发现用户 A 所在的会话陷入等待，如果超时（这个时间可以进行配置），会出现 Lock wait time out 提示：

![1154170-20190905233406353-1460998285.jpg][]

如果在等待期间我们用户 B 所在的会话事务提交，那么用户 A 所在的事务的写操作将提示操作成功。

#### 结论四： ####

**当我们将当前会话的隔离级别设置为 serializable 的时候，其他会话对该表的写操作将被挂起。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的。**

转载于:https://www.cnblogs.com/xinruyi/p/11470546.html

[1154170-20190905231406355-1110618932.jpg]: /images/20230601/84ebf117c15240eb87bca701f2ddb1a0.png
[1154170-20190905231441354-1756581354.jpg]: /images/20230601/7675e1c704584e7c9b03b95a4f719ac7.png
[1154170-20190905231622378-1206867913.jpg]: /images/20230601/07216e4e022d4942ae6cbec00971cfc0.png
[1154170-20190905231743971-1454978260.jpg]: /images/20230601/4c2d7ddee99d43ccb76b6e1fb44cedb7.png
[1154170-20190905232035352-1842869615.jpg]: /images/20230601/dca82f7276674439bd8b618e363e0b76.png
[1154170-20190905232114350-125423140.jpg]: /images/20230601/31292c30beeb4537ad2a6e8da8064944.png
[1154170-20190905232218357-1032391177.jpg]: /images/20230601/54e1c84a5cdc495f9fe2a660f524a8db.png
[1154170-20190905232522350-402370589.jpg]: /images/20230601/0ed8253e3b4b4e75a3e3ab977ccd7dd6.png
[1154170-20190905232642349-196621036.jpg]: /images/20230601/0c47ae3f0f0b44d391919fa3e2fc57d8.png
[1154170-20190905232735390-1301364922.jpg]: /images/20230601/93c8c7ff83e343709c195c841574163e.png
[1154170-20190905232819359-987389409.jpg]: /images/20230601/ed8146036f044ad49c6b91e997104458.png
[1154170-20190905232903445-633179898.jpg]: /images/20230601/2a543b3a581e4034a0180e79c869061b.png
[1154170-20190905233236358-2123694351.jpg]: /images/20230601/70d86c8082f845468d6e9678e79e7468.png
[1154170-20190905233324355-1087698134.jpg]: /images/20230601/2f1deb12abc6446b8a197c2aca3188cb.png
[1154170-20190905233406353-1460998285.jpg]: /images/20230601/6662558716a7421a86e5210daeb4dbef.png