MySQL事务隔离级别

MySQL 的事务隔离级别可以分为四个等级，即：READ UNCOMMITTED（读未提交数据）、READ COMMITTED（读已提交数据）、REPEATABLE READ（可重复读）和 SERIALIZABLE（串行化）。

什么是事务

数据库事务指的是一组数据操作，事务内的操作要么就是全部成功，要么就是全部失败，什么都不做，其实不是没做，是可能做了一部分但是只要有一步失败，就要回滚所有操作，有点一不做二不休的意思。

假设一个网购付款的操作，用户付款后要涉及到订单状态更新、扣库存以及其他一系列动作，这就是一个事务，如果一切正常那就相安无事，一旦中间有某个环节异常，那整个事务就要回滚，总不能更新了订单状态但是不扣库存吧，这问题就大了。

事务具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）四个特性，简称 ACID，缺一不可。

MySQL事务隔离级别详解

事务隔离级别

SQL 标准定义了四种隔离级别，MySQL 全都支持。这四种隔离级别分别是：

读未提交（READ UNCOMMITTED）
读提交（READ COMMITTED）
可重复读（REPEATABLE READ）
串行化（SERIALIZABLE）

从上往下，隔离强度逐渐增强，性能逐渐变差。采用哪种隔离级别要根据系统需求权衡决定，其中，可重复读是 MySQL 的默认级别。事务隔离其实就是为了解决上面提到的脏读、不可重复读、幻读这几个问题，下面展示了 4 种隔离级别对这三个问题的解决程度。

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	可能	可能	可能
不可重复读（read-committed）	不可能	可能	可能
可重复读（repeatable-read）	不可能	不可能	可能
串行化（serializable）	不可能	不可能	不可能

只有串行化的隔离级别解决了全部这 3 个问题，其他的 3 个隔离级别都有缺陷。

查看隔离级别

我们可以通过以下语句查看当前数据库的隔离级别，5.7.20 之前的版本：

show variables like 'transaction_isolation';
# 等同于上面的语句
SELECT @@transaction_isolation;

5.7.20 之后的版本：

SELECT @@tx_isolation;
# 等同于上面的语句
show variables like 'tx_isolation';

我们在 MySQL 下执行完毕后，如下图所示：

16_MySQL事务隔离级别.png

我们看到，此时就是默认的 REPEATABLE-READ，也就是可重复读。

设置隔离级别

修改隔离级别的语句是：

set [作用域] transaction isolation level [事务隔离级别]

其中作用于可以是 SESSION 或者 GLOBAL，GLOBAL 是全局的，而 SESSION 只针对当前回话窗口。隔离级别是 {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE} 这四种，不区分大小写，也就是修改隔离级别的语句为：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

比如下面这个语句的意思是设置全局隔离级别为读提交级别：

set global transaction isolation level read committed;

MySQL中执行事务

事务的执行过程如下，以 begin 或者 start transaction 开始，然后执行一系列操作，最后要执行 commit 操作，事务才算结束。当然，如果进行回滚操作(rollback)，事务也会结束，流程如下：

17_MySQL事务隔离级别.png

需要注意的是，begin 命令并不代表事务的开始，事务开始于 begin 命令之后的第一条语句执行的时候。例如下面示例中，select * from xxx 才是事务的开始：

begin;
select * from xxx; 
commit; -- 或者 rollback;

另外，通过以下语句可以查询当前有多少事务正在运行：

select * from information_schema.innodb_trx;

案例

数据准备

我们首先创建一张表，具体语句如下：

use test;
CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) DEFAULT NULL,
  `age` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

插入一条记录，具体语句如下：

INSERT INTO user(id, name, age)VALUES(1, "嗨客网", 1);

我们使用如下语句，查看记录：

SELECT * FROM user;

执行完毕后，如下图所示：

18_MySQL事务隔离级别.png

读未提交

MySQL 事务隔离其实是依靠锁来实现的，加锁自然会带来性能的损失。而读未提交隔离级别是不加锁的，所以它的性能是最好的，没有加锁、解锁带来的性能开销。但有利就有弊，这基本上就相当于裸奔啊，所以它连脏读的问题都没办法解决。

任何事务对数据的修改都会第一时间暴露给其他事务，即使事务还没有提交，下面来做个简单实验验证一下，首先设置全局隔离级别为读未提交，具体语句如下：

set global transaction isolation level read uncommitted;

设置完成后，只对之后新起的 session 才起作用，对已经启动 session 无效。如果用 shell 客户端那就要重新连接 MySQL，如果用 Navicat 那就要创建新的查询窗口。我们查看当前的隔离级别，具体语句如下：

SELECT @@tx_isolation;

执行完毕后，如下图所示：

19_MySQL事务隔离级别.png

即，我们的设置已经生效了。现在，启动两个事务，分别为事务 A 和事务 B，在事务 A 中使用 update 语句，修改 age 的值为 10，初始是 1 ，在执行完 update 语句之后，在事务 B 中查询 user 表，会看到 age 的值已经是 10 了，这时候事务 A 还没有提交，而此时事务 B 有可能拿着已经修改过的 age=10 去进行其他操作了。

在事务 B 进行操作的过程中，很有可能事务 A 由于某些原因，进行了事务回滚操作，那其实事务 B 得到的就是脏数据了，拿着脏数据去进行其他的计算，那结果肯定也是有问题的。

具体操作流程如下，我们首先打开两个 mysql 连接用来开启两个事务，我们首先在终端1开启事务，并执行查询操作，具体命令如下：

-- 开启事务
BEGIN;
-- 执行查询
SELECT * FROM user;

此时，如下图所示：

20_MySQL事务隔离级别.png

现在，我们再次在终端2开启事务，具体命令如下：

-- 开启事务
BEGIN;
-- 执行查询
SELECT * FROM user;

此时，如下图所示：

21_MySQL事务隔离级别.png

现在，我们在终端1里面更新 age 字段的值，具体命令如下：

UPDATE FROM user SET age=10 WHERE id=1;
SELECT * FROM user;

此时，如下图所示：

22_MySQL事务隔离级别.png

现在，我们在终端2执行查询操作，具体命令如下：

SELECT * FROM user;

此时，如下图所示：

23_MySQL事务隔离级别.png

我们看到，此时终端2，也就是事务 B 查看到的 age 字段的值为 10，此时事务2的所有操作都会将 age 的值当做 10 来操作，现在，我们在终端1将刚才的事务回滚，即执行如下语句：

ROLLBACK;
SELECT * FROM user;

此时，如下图所示：

24_MySQL事务隔离级别.png

我们看到，此时事务 B 就出现了读取到未提交的数据了，整个事件的流程如下：

25_MySQL事务隔离级别.png

读未提交，其实就是可以读到其他事务未提交的数据，但没有办法保证你读到的数据最终一定是提交后的数据，如果中间发生回滚，那就会出现脏数据问题，读未提交没办法解决脏数据问题。更别提可重复读和幻读了，想都不要想。

读提交

既然读未提交没办法解决脏数据问题，那么就有了读提交。读提交就是一个事务只能读到其他事务已经提交过的数据，也就是其他事务调用 commit 命令之后的数据。那脏数据问题迎刃而解了。

读提交事务隔离级别是大多数流行数据库的默认事务隔离界别，比如 Oracle，但是不是 MySQL 的默认隔离界别。

我们继续来做一下验证，首先把事务隔离级别改为读提交级别：

set global transaction isolation level read committed;

执行完毕后，同样，我们需要重新连接 MySQL，修改完毕后，如下图所示：

26_MySQL事务隔离级别.png

同样开启事务 A 和事务 B 两个事务，在事务 A 中使用 update 语句将 id=1 的记录行 age 字段改为 10。此时，在事务B中使用 select 语句进行查询，我们发现在事务 A 提交之前，事务B中查询到的记录 age 一直是 1，直到事务 A 提交，此时在事务 B 中 select 查询，发现 age 的值已经是 10 了，流程如下。

我们首先，在事务 A 中开启事务并查询当前的值，具体命令如下：

BEGIN;
SELECT * FROM user;

如下图所示：

27_MySQL事务隔离级别.png

此时，同样，我们在事务 B 中执行同样的操作，如下所示：

BEGIN;
SELECT * FROM user;

如下图所示：

28_MySQL事务隔离级别.png

现在，我们在事务 A 中更新 age 的值，具体命令如下：

UPDATE user SET age=10 WHERE id=1;

执行完毕后，我们在事务 A 查看当前数据，具体命令如下：

SELECT * FROM user;

如下图所示：

29_MySQL事务隔离级别.png

现在，我们在事务 B 中同样查看数据，此时事务 B 如下图所示：

30_MySQL事务隔离级别.png

我们看到，此时虽然事务 A 更新了 age 为 10，但事务 B 的 age 此时查询到的还是 1，现在，我们提交事务 A，具体命令如下：

COMMIT;

现在，我们在事务 B 中再次查看数据，如下图所示：

31_MySQL事务隔离级别.png

我们看到，此时事务 B 看到的数据已经是更新后的数据了，整个流程如下：

32_MySQL事务隔离级别.png

每个 select 语句都有自己的一份快照，而不是一个事务一份，所以在不同的时刻，查询出来的数据可能是不一致的。

读提交解决了脏读的问题，但是无法做到可重复读，也没办法解决幻读。

可重复读

可重复是对比不可重复而言的，上面说不可重复读是指同一事物不同时刻读到的数据值可能不一致。而可重复读是指，事务不会读到其他事务对已有数据的修改，及时其他事务已提交，也就是说，事务开始时读到的已有数据是什么，在事务提交前的任意时刻，这些数据的值都是一样的。但是，对于其他事务新插入的数据是可以读到的，这也就引发了幻读问题。

同样的，需改全局隔离级别为可重复读级别，具体语句如下：

set global transaction isolation level repeatable read;

同样，执行完毕后，我们需要重新连接，修改完毕后，如下图所示：

33_MySQL事务隔离级别.png

在这个隔离级别下，启动两个事务，两个事务同时开启。首先看一下可重复读的效果，事务 A 启动后修改了数据，并且在事务 B 之前提交，事务 B 在事务开始和事务 A 提交之后两个时间节点都读取的数据相同，已经可以看出可重复读的效果，具体操作如下：

我们首先开启事务 A，并且查看当前的数据，具体命令如下：

BEGIN;
SELECT * FROM user;

如下图所示：

34_MySQL事务隔离级别.png

此时，同样，我们在事务 B 中执行同样的操作，如下所示：

BEGIN;
SELECT * FROM user;

如下图所示：

35_MySQL事务隔离级别.png

现在，我们在事务 A 中更新 age 的值，并提交事务，具体命令如下：

UPDATE user SET age=10 WHERE id=1;
COMMIT;

执行完毕后，我们在事务 A 查看当前数据，具体命令如下：

SELECT * FROM user;

如下图所示：

36_MySQL事务隔离级别.png

现在，我们在事务 B 中同样查看数据，此时事务 B 如下图所示：

37_MySQL事务隔离级别.png

我们看到，此时虽然事务 A 更新了 age 为 10 并且已经提交了事务，但事务 B 的 age 此时查询到的还是 1，因为，事务 A 和 B 是同时开启的，但事务 B 还未提交，因此，在整个事务 B 过程中，数据都是一致的，现在，我们提交事务 B，具体命令如下：

COMMIT;

现在，我们在事务 B 中再次查看数据，如下图所示：

38_MySQL事务隔离级别.png

我们看到，此时事务 B 看到的数据已经是更新后的数据了，整个流程如下：

39_MySQL事务隔离级别.png

可重复读做到了，这只是针对已有行的更改操作有效，但是对于新插入的行记录，就没这么幸运了，幻读就这么产生了，我们看一下这个过程：

事务 A 开始后，执行 update 操作，将 age = 1 的记录的 name 改为 “haicoder”；

事务 B 开始后，在事务执行完 update 后，执行 insert 操作，插入记录 age = 1，name = “嗨客网”，这和事务 A 修改的那条记录值相同，然后提交。

事务 B 提交后，事务 A 中执行 select，查询 age=1 的数据，这时，会发现多了一行，并且发现还有一条 name = “嗨客网”，age = 1 的记录，这其实就是事务 B 刚刚插入的，这就是幻读。

具体操作，我们首先开启事务 A，并查看当前数据，具体命令如下：

BEGIN;
SELECT * FROM user;

如下图所示：

40_MySQL事务隔离级别.png

同时，现在我们开启事务 B，并查看当前数据，如下图所示：

41_MySQL事务隔离级别.png

现在，我们在事务 A 中更新 id 为 1 的记录的 name 为 haicoder，具体命令如下：

UPDATE user SET name='haicoder' WHERE id=1;

执行完毕后，我们再次查看当前数据，如下图所示：

42_MySQL事务隔离级别.png

现在，我们在事务 B 中插入一条 id 为 2，name 为 “嗨客网” 并且 age 为 1 的记录，具体命令如下：

INSERT INTO user(id, name, age)VALUES(2, "嗨客网", 1);

执行完毕后，我们在事务 B 查看数据，此时如下图所示：

43_MySQL事务隔离级别.png

现在，我们提交事务 B，具体命令如下：

COMMIT;

现在，我们再次在事务 A 中查看当前数据，此时如下图所示：

44_MySQL事务隔离级别.png

要说明的是，当你在 MySQL 中测试幻读的时候，并不会出现上图的结果，幻读并没有发生，MySQL 的可重复读隔离级别其实解决了幻读问题，整个过程如下：

45_MySQL事务隔离级别.png

串行化

串行化是 4 种事务隔离级别中隔离效果最好的，解决了脏读、可重复读、幻读的问题，但是效果最差，它将事务的执行变为顺序执行，与其他三个隔离级别相比，它就相当于单线程，后一个事务的执行必须等待前一个事务结束。

MySQL中是如何实现事务隔离的

首先说读未提交，它是性能最好，也可以说它是最野蛮的方式，因为它压根儿就不加锁，所以根本谈不上什么隔离效果，可以理解为没有隔离。

再来说串行化。读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。

最后说读提交和可重复读。这两种隔离级别是比较复杂的，既要允许一定的并发，又想要兼顾的解决问题。

实现可重复读

为了解决不可重复读，或者为了实现可重复读，MySQL 采用了 MVVC (多版本并发控制) 的方式。

我们在数据库表中看到的一行记录可能实际上有多个版本，每个版本的记录除了有数据本身外，还要有一个表示版本的字段，记为 row trx_id，而这个字段就是使其产生的事务的 id，事务 ID 记为 transaction id，它在事务开始的时候向事务系统申请，按时间先后顺序递增。

46_MySQL事务隔离级别.png

按照上面这张图理解，一行记录现在有 3 个版本，每一个版本都记录这使其产生的事务 ID，比如事务 A 的 transaction id 是 100，那么版本 1 的 row trx_id 就是 100，同理版本 2 和版本 3。

在上面介绍读提交和可重复读的时候都提到了一个词，叫做快照，学名叫做一致性视图，这也是可重复读和不可重复读的关键，可重复读是在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照。

对于一个快照来说，它能够读到那些版本数据，要遵循以下规则：

当前事务内的更新，可以读到；
版本未提交，不能读到；
版本已提交，但是却在快照创建后提交的，不能读到；
版本已提交，且是在快照创建前提交的，可以读到；

利用上面的规则，再返回去套用到读提交和可重复读的那两张图上就很清晰了。还是要强调，两者主要的区别就是在快照的创建上，可重复读仅在事务开始是创建一次，而读提交每次执行语句的时候都要重新创建一次。

并发写问题

存在这的情况，两个事务，对同一条数据做修改。最后结果应该是哪个事务的结果呢，肯定要是时间靠后的那个对不对。并且更新之前要先读数据，这里所说的读和上面说到的读不一样，更新之前的读叫做 “当前读”，总是当前版本的数据，也就是多版本中最新一次提交的那版。

假设事务 A 执行 update 操作， update 的时候要对所修改的行加行锁，这个行锁会在提交之后才释放。而在事务 A 提交之前，事务 B 也想 update 这行数据，于是申请行锁，但是由于已经被事务 A 占有，事务 B 是申请不到的，此时，事务 B 就会一直处于等待状态，直到事务 A 提交，事务 B 才能继续执行，如果事务 A 的时间太长，那么事务 B 很有可能出现超时异常，如下图所示：

47_MySQL事务隔离级别.png

加锁的过程要分有索引和无索引两种情况，比如下面这条语句：

update user set age=11 where id = 1;

id 是这张表的主键，是有索引的情况，那么 MySQL 直接就在索引数中找到了这行数据，然后干净利落的加上行锁就可以了。而下面这条语句：

update user set age=11 where age=10;

表中并没有为 age 字段设置索引，所以， MySQL 无法直接定位到这行数据。那怎么办呢，当然也不是加表锁了。MySQL 会为这张表中所有行加行锁，没错，是所有行。但是呢，在加上行锁后，MySQL 会进行一遍过滤，发现不满足的行就释放锁，最终只留下符合条件的行。虽然最终只为符合条件的行加了锁，但是这一锁一释放的过程对性能也是影响极大的。所以，如果是大表的话，建议合理设计索引，如果真的出现这种情况，那很难保证并发度。

解决幻读

上面介绍可重复读的时候，那张图里标示着出现幻读的地方实际上在 MySQL 中并不会出现，MySQL 已经在可重复读隔离级别下解决了幻读的问题。

前面刚说了并发写问题的解决方式就是行锁，而解决幻读用的也是锁，叫做间隙锁，MySQL 把行锁和间隙锁合并在一起，解决了并发写和幻读的问题，这个锁叫做 Next-Key 锁。

假设现在表中有两条记录，并且 age 字段已经添加了索引，两条记录 age 的值分别为 10 和 30。

48_MySQL事务隔离级别.png

此时，在数据库中会为索引维护一套 B+ 树，用来快速定位行记录。B+ 索引树是有序的，所以会把这张表的索引分割成几个区间。

49_MySQL事务隔离级别.png

如图所示，分成了 3 个区间，(负无穷,10]、(10,30]、(30,正无穷]，在这 3 个区间是可以加间隙锁的。之后，我用下面的两个事务演示一下加锁过程：

50_MySQL事务隔离级别.png

在事务 A 提交之前，事务 B 的插入操作只能等待，这就是间隙锁起得作用。当事务 A 执行 update user set name=‘haicoder’ where age = 10; 的时候，由于条件 where age = 10 ，数据库不仅在 age =10 的行上添加了行锁，而且在这条记录的两边，也就是(负无穷,10]、(10,30] 这两个区间加了间隙锁，从而导致事务B插入操作无法完成，只能等待事务 A 提交。不仅插入 age = 10 的记录需要等待事务 A 提交，age<10、10<age<30 的记录页无法完成，而大于等于 30 的记录则不受影响，这足以解决幻读问题了。

这是有索引的情况，如果 age 不是索引列，那么数据库会为整个表加上间隙锁。所以，如果是没有索引的话，不管 age 是否大于等于30，都要等待事务 A 提交才可以成功插入。

总结

MySQL 的 InnoDB 引擎才支持事务，其中可重复读是默认的隔离级别。

读未提交和串行化基本上是不需要考虑的隔离级别，前者不加锁限制，后者相当于单线程执行，效率太差。

读提交解决了脏读问题，行锁解决了并发更新的问题。并且 MySQL 在可重复读级别解决了幻读问题，是通过行锁和间隙锁的组合 Next-Key 锁实现的。

MySQL事务隔离级别

什么是事务

MySQL事务隔离级别详解

相关概念

脏读

可重复读

不可重复读

幻读

事务隔离级别

查看隔离级别

设置隔离级别

MySQL中执行事务

案例

数据准备

读未提交

读提交

可重复读

串行化

MySQL中是如何实现事务隔离的

实现可重复读

并发写问题

解决幻读

总结