InnoDB之事务隔离级别

前言

在和同学讨论幻读问题的时候，他们都认为在REPEATABLE READ隔离级别下可能会产生幻读问题，于是在网上查询相关资料也说可能会产生幻读问题。在这篇文章中我会介绍四种事务隔离级别，并通过结合书中的内容阐述自己对于幻读问题的理解以及自己对于REPEATABLE READ隔离级别下是否会产生幻读问题的理解。（MySQL官方文档中将不可重复读定义为幻读<Phantom Problem>）

基础

事务的特点（ACID）

原子性（atomicity）
一致性（consistency）
隔离性（isolation）
持久性（durability）

InnoBD存储引擎通过redo log（重做日志）实现事务的原子性和持久性，通过undo log实现事务的一致性，通过锁实现事务的隔离性。这里重点介绍不同的锁实现与对应的隔离级别对于事务的影响。

行锁的三种实现

Record Lock: 单个行记录上的锁。
Gap Lock: 间隙锁，锁定一个范围，但不包括记录本身。
Next-Key Lock: Gap Lock + Record Lock,锁定一个范围，并且锁住记录本身。

Next-Key Lock: 如果索引有10，11，13，20四个值，可能被Next-Key Locking锁定的区间为：

$(-\infty, 10],(10, 11], (11, 13], (13,\infty]$

Next-Key Lock优化：当查询的索引是唯一索引的情况下，InnoDB存储引擎会对Next-Key Lock进行优化，将其降级为Record Lock, 即仅锁住索引本身。而不是范围。我们来看下面的例子。

CREATE TABLE z ( a INT, b INT, PRIMARY KEY(a), KEY(b) );
INSERT INTO z SELECT 1,1;
INSERT INTO z SELECT 3,1;
INSERT INTO z SELECT 5,1;
INSERT INTO z SELECT 7,1;
INSERT INTO z SELECT 10,1;

表z中a列为聚集索引，b列为辅组索引，且当前的事务隔离级别为InnoDB默认的REPEATABLE READ。若在会话A中执行如下sql语句。

SELECT * FROM z WHERE b=3 FOR UPDATE

FOR UPDATE用于显式地对数据库读取操作加上互斥锁。由于通过b列进行查找，并且存在两个索引，查找过程需要分别进行加锁。对于聚集索引，仅对列a中等于5的索引加上了Record Lock。而对于辅助索引，使用了Next-Key Lock锁定了范围（1,3]，需要要特别注意的是，InnoDB存储引擎还会对辅助索引下一个键值加上Gao Lock, 即锁定范围（3, 6)。因此当此时会话B中运行如下sql语句时，都会被阻塞：

SELECT * FROM z WHERE a=5 LOCK IN SHARE MODE
INSERT INTO z SELECT 4,2  //辅助索引的（1,3]被锁定，因此b列中插入2的操作被阻塞
INSERT INTO z SELECT 6,5  //辅助索引的（3,6]被锁定，因此b列中插入5的操作被阻塞

事务隔离级别与锁算法

READ UNCOMMITTED——可以读到其他事务未提交的修改
READ COMMITTED——除了唯一性约束检查以及外键约束检查需要gap lock外，InnoDB只会使用Record Lock
REPEATABLE READ——使用Next-Key Lock
SERIALIZABLE——对每个SELECT语句后自动加上LOCK IN SHARE MODE，对一致性的非锁定读不在支持

一致性非锁定读（Multi Version Concurrency Control, MVCC）

为了提升并发性能，InnoDB存储引擎在不显示加锁的情况下的读取操作都是不加锁的。即如果读取的行正在执行DELETE或UPDATE操作（即该行上被加上了X锁），这时读取操作不会去等待行上锁的释放，而是去读取行的一个快照信息，即该行上之前版本的数据，该实现是通过undo段来实现的。对于不同的事务隔离级别，读取方式也不同，需要注意的是并不是每个事务隔离级别下都支持一致性非锁定读。

READ COMMITTED——总是读取最新的快照信息。读取最新的版本，会产生幻读。
REPEATABLE READ——读取事务开始时的快照信息，由于总是读取事务开始时的快照版本，因此不会产生幻读。

加入parent表中有一行id=1的数据。

时间	会话A	会话B
1	BEGIN
2		BEGIN
3		UPDATE parent SET id=3 WHERE id=1;
4	SELECT*FROM parnt WHERE id=1;
5		COMMIT;
6	SELECT*FROM parnt WHERE id=1;
7	COMMIT
8

情况1：当前的事务级别为READ COMMITTED，由于会话B的更新操作对id=1的行加上了X锁，所以会话A在时间点4无法访问id=1这一行的数据，所以只能从最新的快照信息中读取就版本的数据，即读到的是id=1；在时间点6时，由于会话B的事务已提交，因此更新的最新的快照信息，因此当会话A在时间点6访问最新的快照信息时已经没有id=1的数据了，所以返回Empty。（出现了幻读问题）

情况2：当前的事务级别为REPEATABLE READ，由于该事务隔离级别下总是访问事务开始时的快照版本，即时间点1的快照信息版本，所以无论会话B做出怎样的修改，会话A中的事务总是读取时间点1时（事务开始时）的快照信息，即id=1。（不会出现幻读问题）

一致性锁定读

显式地为读取操作加锁：

SELECT...FOR UPDATE——对读取地行加X锁（互斥锁）
SELECT...LOCK IN SHARE MODE——对读取地行加S锁（共享锁）

需要注意的点：X锁和X锁以及X锁和S锁是不兼容的，只有S锁和S锁是兼容的。

什么是幻读

在同一个事务下，连续执行两次同样的SQL语句可能导致不同的结果，即第二次的SQL语句可能会返回之前不存在的行。

什么操作会产生幻读问题（个人见解）

不加锁读：INSERT, UPDATE, DELETE
加锁读：INSERT

如何解决幻读问题

innoDB存储引擎通过Next-Key Lock来解决幻读问题。加入表t中有a=2和a=5的行记录。

时间	会话A	会话B
1	BEGIN
2	SELECT * FROM t WHERE a>2 FOR UPDATE
3		BEGIN
4		INSERT INTO t SELECT 4;
5		COMMIT
6	SELECT * FROM t WHERE a>2 FOR UPDATE
7	COMMIT

情况1：当前的事务级别为READ COMMITTED，即使用的Record Lock，会话A中事务会将a=5这一行上X锁，并返回a=2的行记录，但这并不影响会话B中的事务插入a=4的行记录的操作，所以会话A在时间点6执行同样的读取操作时返回的是a=2和a=4的行记录。（出现了幻读问题）

情况2：当前的事务级别为REPEATABLE READ，会话A会使用Next-Key Lock对

$（2，+\infty）$

这个范围加上了X锁，因此会话B在时间点4对于这个范围的任何操作都会阻塞。（不会出现幻读问题）

总结

隔离级别REPEATABLE READ在加锁读和不加锁读都不会出现幻读现象。