MySQL Innodb数据库引擎的事务隔离级别

前言

在讲事务的隔离级别之前，先简单的复习下什么是事务？（了解的同学可以跳过）

• 在MySQL中只有使用了Innodb数据库引擎的数据库或表才支持事务。每执行一条增删改查的sql都是一次事务，只不过autocommit默认是开启的，所以自动提交了。

• 事务必须满足的4个条件：

  • 原子性（或称不可分割性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

  • 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

  • 隔离性（又称独立性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable），这也是本文章要讲的内容。

  • 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

多事务并发的问题

当有多个事务并发操作数据库表的时候，可能会出现以下问题：

• 脏读（读取未提交的数据）：脏读又称无效数据的读出，是指在数据库访问中，事务 A 对一个值做修改，事务 B 读取这个值，但是由于某种原因事务 A 回滚撤销了对这个值得修改，这就导致事务 B 读取到的值是无效数据。

  时间	事务A	事务B
  t1	开启事务	开启事务
  t2	查询张三账户余额为0
  t3	给张三转账1000
  t4		查询张三账户余额为1000（脏读）
  t5	发现转错，撤回1000
  t6	提交事务	提交事务

• 不可重复读（前后数据多次读取，结果集内容不一致）：不可重复读即当事务 A 按照查询条件得到了一个结果集，这时事务 B 对事务 A 查询的结果集数据做了修改操作，之后事务 A 为了数据校验继续按照之前的查询条件得到的结果集与前一次查询不同，导致不可重复读取原始数据。

  时间	事务A	事务B
  t1	开启事务	开启事务
  t2	查询张三账户余额为0	查询张三账户余额为0
  t3		给张三转账1000
  t4		提交事务
  t5	查询张三账户余额为1000（不可重复读）
  t6	提交事务

• 幻读（前后数据多次读取，结果集数量不一致）：幻读是指当事务 A 按照查询条件得到了一个结果集，这时事务 B 对事务 A 查询的结果集数据做新增操作，之后事务 A 继续按照之前的查询条件得到的结果集平白无故多了几条数据。

  时间	事务A	事务B
  t1	开启事务	开启事务
  t2	查询张三账户交易次数，返回2次
  t3		张三按摩消费888，交易次数+1
  t4		提交事务
  t5	查询张三账户交易次数，返回3次（幻读）
  t6	提交事务

很多人容易搞混不可重复读和幻读，确实这两者有些相似：一个是结果内容不同；一个是结果数量不同。但不可重复读重点在于update和delete，而幻读的重点在于insert，且两者的解决方法也大有不同。
如果使用锁机制来解决问题，在可重复读中，update sql第一次读取到数据后，就将这些数据加行锁，其它事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以不能通过行锁来避免幻读，需要用到表锁或者间隙锁，但会极大的降低数据库的并发能力。

事务的隔离级别

针对上述脏读、不可重复读和幻读三个问题，数据库大佬们提出了一个解决思路，也就是我们本文的主角——事务隔离。

事务隔离由低到高分为四个级别：

• 读未提交（Read uncommitted）：读若不显式声明是不加锁的，可以读取到另一个事务未提交的数据修改，没有避免脏读、不可重复读、幻读。

• 读已提交（Read committed）：一个事务只能读取到另一个事务已经提交的数据修改，这种隔离级别避免了脏读，但是可能会出现不可重复读、幻读。

• 可重复读（Repeatable read）：保证了同一事务下多次读取相同的数据返回的结果集是一样的，这种隔离级别解决了脏读和不可重复读问题，但是仍有可能出现幻读。

• 可串行化（Serializable）：对同一数据的读写全加锁，即对同一数据的读写全是互斥了，数据可靠行很强，但是并发性能不忍直视。这种隔离级别虽然解决了上述三个问题，但是牺牲了性能。

Innodb事务隔离的实现

1. Innodb默认隔离级别

在讲事务隔离的实现之前，我们先来了解一下其默认的隔离级别是什么。

Innodb的默认隔离级别是可重复读，可以通过以下两种方式来变更隔离级别：
全局修改，修改mysql.ini配置文件，在最后加上

#可选参数有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.
[mysqld]
transaction-isolation = SERIALIZABLE

也可通过执行语句改变单个会话或全局的事务隔离级别

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

然后可以通过以下语句来查询当前隔离级别：

select @@tx_isolation;

2. MVCC

MVCC((Mutil-Version Concurrency Control))，全称多版本并发访问,这是一种并发环境下进行数据安全控制的方法，Innodb通过MVCC来实现提交读(Read committed)和可重复读(Repeatable read)这两种隔离级别。通过MVCC + 锁的方式来实现可串行化(Serializable)隔离级别。

假如有一个表player，你以为它是长这个样子的:

id	name	num
1	kobe	24

但实际上它是长这个样子的：

id	player	num	trx_id	roll_pointer
1	kobe	24	1	指向上一个版本记录的Undo Log日志位置

trx_id：只要有任意一个事务对某条聚簇索引记录进行修改，该事务id就会被记录到该字段里面。

roll_pointer：当任意一个聚簇索引记录被修改，上一个版本的数据记录就会被写入Undo Log日志里面。这个roll_pointer就是存储了一个指针，这个指针是一个地址，指向这个聚簇索引的上一个版本的记录位置，通过这个指针就可以获得到每一个历史版本的记录。

Undo log：Undo Log是MySQL的三大日志之一，当我们对记录做了变更操作时就会产生一条Undo记录。它的作用就是保护事务在异常发生的时候或手动回滚时可以回滚到历史版本数据，能够让你读取过去某一个时间点保存的数据。

如果到这里你还有点懵，没事，接下来我们通过一个场景来更直观的感受一下：

有一个事务A，事务id为2，它执行了一下操作

update player set num = 8 where id = 1;

那么，这条记录的trx_id隐藏字段就会记录此次插入记录的事务ID：

这些是不是清晰一点了，其实每一次update或者insert操作，都会写入到Undo Log日志，而读操作只需要根据规则去查看对应的某一个版本，这个规则就是Read View。

Read View 存放着一个列表，这个列表用来记录当前数据库系统中活跃的读写事务，也就是正在进行数据操作但是还未提交保存的事务。其中，有四个重要的字段：

• creator_trx_id：创建当前Read View所对应的事务ID
• m_ids：所有当前未提交事务的事务ID，也就是活跃事务的事务id列表
• min_trx_id：m_ids里最小的事务id值
• max_trx_id：InnoDB 需要分配给下一个事务的事务ID值（事务 ID 是累计递增分配的，所以后面分配的事务ID一定会比前面的大！）

文字总是干巴巴的，下边通过场景，图文并茂的带你了解MVCC是怎样实现可重复读的，以及Read View的作用。

现在两个事务B和C，B的事务id为3，C的事务id为4，还是刚刚的player表：

id	player	num	trx_id	roll_pointer
1	kobe	8	2	指向上一个版本记录的Undo Log日志位置

事务B和C将并发做以下操作：

时间	事务B	事务C
t1	开启事务	开启事务
t2	select num from player where id = 1
t3		update player set num = 10 where id = 1;
t4		提交事务
t5	select num from player where id = 1
t6	提交事务

t1时间，这两个事务就会创建各自的Read View：

事务 B	事务 C
creator_trx_id = 3	creator_trx_id = 4
m_ids = [3,4]	m_ids = [3,4]
min_trx_id = 3	min_trx_id = 3
max_trx_id = 5	max_trx_id = 5

t2时间，事务B去读取id=1的数据，找到了记录后就会去查看该记录的trx_id，事务B查看到该记录的trx_id值为2,随后和自己的creator_trx_id值进行比较，发现trx_id = 2 < 自己的creator_trx_id = 3，就判断到该记录的事务id不存在于活跃的事务列表中并且小于自己的事务id（也是通过此举来实现读已提交隔离级别），这代表本次记录的值是在自己查询之前提交的，便可以读取到num=8。

t3时间，事务C执行了更新操作，并把id=1的trx_id置为4，并把roll_pointer指向trx_id = 2的Undo Log记录。

t4时间，事务C提交，Read View抹除事务C相关数据：

事务 B	-
creator_trx_id = 3
m_ids = [3]
min_trx_id = 3
max_trx_id = 5

t5时间，事务B再次读取id=1的数据，事务B查看到该记录的trx_id值为4,随后和自己的creator_trx_id值进行比较，发现trx_id = 4 > 自己的creator_trx_id = 3，所以不会直接读取此时的数据，而是通过roll_pointer找到上一个版本，再进行一个trx_id和creator_trx_id的比较，一直找到trx_id < 自己的creator_trx_id，且该trx_id不在m_ids内的数据为止，这样就避免了不可重复读的情况。

3. 总结

通过以上描述，我们就可以清楚的知道：InnoDB 中，MVCC 就是通过 Undo Log + Read View 进行数据读取，Undo Log 保存了历史快照，而 Read View 规则帮我们判断当前版本的数据是否可见。从而不需要通过加锁的方式，就可以实现提交读和可重复读这两种隔离级别。

那么InnoDB是怎么解决幻读的呢？答案是通过MVCC + 间隙锁(Next-Key Lock)，但是极大的降低数据库的并发能力，所以默认的隔离级别设置为不可重复读。