笔记记录自林晓斌（丁奇）老师的《MySQL实战45讲》sql
（本篇内图片均来自丁奇老师的讲解，若有侵权，请联系我删除）数据库
20） --幻读是什么，幻读有什么问题？session
咱们先来看看表结构和初始化数据：并发
CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `c` (`c`) ) ENGINE=InnoDB; insert into t values(0,0,0),(5,5,5), (10,10,10),(15,15,15),(20,20,20),(25,25,25);
表t除主键id外还有一个索引c，初始化语句在表中插入了6行数据。那么若是有下面这样一段语句设计
begin; select * from t where d=5 for update; commit;
请问是怎么加锁的，加的锁又是何时释放的呢？因为for update，上面的语句会在执行完成select以后加一个写锁，并且因为两阶段锁协议，这个写锁会在执行commit语句的时候释放。因为字段d上没有索引，所以这条查询语句会作全表扫描。那么，其余被扫描到的，可是不知足条件的5行记录上，会不会也被加锁呢？咱们知道，InnoDB的默认隔离级别是可重复读，因此本文接下来没有特殊说明的部分，都是设定在可重复读隔离级别下的。3d
幻读是什么？日志
咱们不妨来分析一下，若是只在d=5，也就是id=5这一行上加锁，其余行上不加锁，会怎么样。咱们来看一下这种状况的场景，注意，这里是符合刚才假设的，只在查询的那一行加锁，其余行不加锁的状况。code
由上图能够看到，在session A中执行了三次查询，分别是Q1,Q2和Q3,他们的查询语句都相同，可是返回结果都不一样。其中Q3读到id=1这一行的现象，被称为“幻读”。也就是说，幻读值得是一个事务在先后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行。这里须要对“幻读”额外说明一下：blog
- 在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。所以，幻读在“当前读”下才会出现。(以前有提到过，update语句是“当前读”，select 语句若是加锁，也是“当前读”)
- 上面的session B的修改结果，被 session A以后的select语句（Q2,Q3）用“当前读”看到，不能称为“幻读”。“幻读”仅专指“新插入的行”。
由于这三次查询都加了for update，都是当前读。根据规则，就是要能读到全部已经提交的记录的最新值，而且Session B和Session C的两条语句执行完成后就会提交，因此Q2和Q3就是应该看到这两个事务的操做效果，并且也看到了，这跟事务的可见性规则并不矛盾。但这是否是真的没有问题呢？不，这还真有一些问题。索引
幻读有什么问题？
首先是语义上的问题。Session A在T1时刻的查询里包含for update，意思是“我要把全部d=5的行锁住，不许别的事务进行读写操做”。但实际上，这个语义被破坏掉了。若是这样还不够明显，能够想象一下，在T2时刻Session B中若是添加这样一条语句：update t set c = 5 where id = 0；Session A的语义是 全部d=5的行锁住，不许别的事务进行读写操做。但在T2时刻，Session B中id=0这一行没有被Session A的声明锁住，同时，因为是在同一个事务中，对id=0(d=5)这一行的更新操做也能正常执行。
其次，是数据一致性的问题。咱们知道，锁的设计是为了保证数据的一致性。而这一致性，不止是数据库内部数据状态在此刻的一致性，还包含了数据和日志在逻辑上的一致性。为了说明这个问题，咱们给session A在T1时刻再加上一个更新语句，即：update t set d = 100 where d = 5；
update的加锁语义和select ...for update是一致的，因此这时候加上这条update语句也很合理。session A声明说“要给d=5的这条语句加上锁”，也就是为了要更新数据，新加的这条update语句就把它认为加上了锁的这一行的d值修改为100.咱们来分析一下上图执行完成以后，数据库里会是什么结果。
- 通过T1时刻，id=5这一行变成了(5,5,100),固然这个结果最终是在T6时刻正式提交的；
- 通过T2时刻，id=0这一行变成了(0,5,5);
- 通过T4时刻，表里面多了一行(1,5,5);
- 其余行跟这个执行序列无关，保持不变。
这样看起来，这些数据页没什么问题。可是咱们再来看看binlog里的内容
- T2时刻，Session B事务提交，写入了两条语句。
- T4时刻，Session C事务提交，写入了两条语句。
- T6时刻，Session A事务提交，写入了update t set d = 100 where d = 5这条语句。
咱们把这些语句统一放到一块儿的话，就是这样的：
update t set d=5 where id=0; /*(0,0,5)*/ update t set c=5 where id=0; /*(0,5,5)*/ insert into t values(1,1,5); /*(1,1,5)*/ update t set c=5 where id=1; /*(1,5,5)*/ update t set d=100 where d=5;/* 全部 d=5 的行，d 改为 100*/
你应该能够看出问题了。这个语句序列，不管是拿到备库执行，仍是之后用binlog来克隆一个库，这三行的结果会变成(0,5,100),(1,5,100),(5,5,100)。也就是说，id=0和id=1这两行，发生了数据不一致。这个问题很严重，是不行的。咱们再来仔细思考一下，这个数据不一致究竟是怎么引入的？
咱们分析一下能够知道，这是咱们假设“select * from t where d = 5 for update这条语句只给d=5这一行，也就是id=5的这一行加锁”致使的。因此咱们能够认为上面的设定不合理，须要更改。那要怎么改呢，咱们把扫描中碰到的行，也都加上写锁，再来看看执行效果。
因为Session A把全部的行都加上了写锁，因此Session B在执行第一个update语句的时候就被锁住了。须要等到T6时刻Session A提交后，Session B才能继续执行。这样，对于id=0这一行，在数据库里的最终结果仍是（0,5,5）。在binlog里面，执行序列是这样的：
insert into t values(1,1,5); /*(1,1,5)*/ update t set c=5 where id=1; /*(1,5,5)*/ update t set d=100 where d=5;/* 全部 d=5 的行，d 改为 100*/ update t set d=5 where id=0; /*(0,0,5)*/ update t set c=5 where id=0; /*(0,5,5)*/
能够看到，按照日志顺序执行，id=0这一行的最终结果也是(0,5,5).因此，id=0这一行的问题解决了。但同时你也会看到，id=1这一行，在数据库里面的结果是(1,5,5),而根据binlog的执行结果是（1,5,100），也就是说幻读的问题仍是没有解决。为何咱们已经这么“凶残”地把全部记录都加上锁了，仍是阻止不了这样的问题呢？缘由其实很简单，T3时刻，咱们给全部行加锁的时候，id=1这一行还不存在，不存在天然咱们的锁对它也没有任何办法。也就是说，即便全部记录都加上了锁，仍是阻止不了新插入的记录。这也是为何“幻读”会被单独拿出来解决的缘由。
如何解决幻读？
产生幻读的缘由是，行锁只能锁住行，可是新插入记录这个动做，要更新的是记录之间的“间隙”。所以，为了解决幻读的问题，InnoDB只好引入新的锁，也就是间隙锁（Gap Lock）。顾名思义，间隙锁，锁的是两个值直接的间隙。好比文章开头的表t，初始化插入了6个记录，这就产生了7个间隙。
表t主键索引上的行锁和间隙锁
这样，当你执行select * from t where d = 5 for update的时候，就不止是给数据库中已有的6个记录加上了行锁，还同时加了7个间隙锁。这样就确保了没法再插入新的记录。也就是说，这一行行的扫描结果中，不只给行加上了锁，也给行两边的空隙加上了间隙锁。因此，行是能够加锁的实体，行与行之间的间隙，也是能够加锁的实体。可是间隙锁和咱们以前碰到过的锁都不太同样。好比行锁，分红读锁和写锁。斜土就是这两种类型锁的冲突关系：
也就是说，跟行锁有冲突关系的是“另外一个行锁”。可是间隙锁不同，跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个操做。间隙锁之间都不存在冲突关系。这句话不是很容易理解，咱们来举个例子：
这里session B不会被锁住。由于表t里并无c=7的记录，所以Session A加间隙锁的间隙是(5，10)。而Session B也是在这个间隙加的间隙锁。它们有共同的目标，即：保护这个间隙，不容许插入值。但，它们之间是不冲突的。间隙锁和行锁合称next-key lock，每一个next-key lock是前开后闭区间。也就是说，咱们的表t初始化之后，若是用select * from t for update要把整个表全部记录锁起来，就造成了7个next-try lock。须要注意的是，结合上面的表t的初始化数据，最后一个区间是 (25, +supremum]。还是前开后闭的。你可能会好奇supremum是什么。由于整无穷是开区间。实现上，InnoDB给每一个索引加了一个不存在的最大值supremum,这样才符合咱们刚才说的“都是前开后闭的区间”。
间隙锁和next-key lock的引入，帮咱们解决了幻读的问题，但同时也带来了一些“困扰”。咱们以这样一个业务逻辑来举例：任意锁住一行，若是这一行不存的话就插入，若是存在这一行就更新它的数据，代码以下：
begin; select * from t where id=N for update; /* 若是行不存在 */ insert into t values(N,N,N); /* 若是行存在 */ update t set d=N set id=N; commit;
可能你会建议使用 insert... on duplicate key update这条语句，但其实在有多个惟一主键的时候这个方法不能知足需求，具体咱们之后会展开说明。如今咱们就单独考虑一下这个逻辑。这种情景下的一个现象是，这个逻辑一旦有并发，就会碰到死锁。你必定有点奇怪，这个逻辑每次操做前都有用for update锁起来，已是最严格的模式了，为何仍是有死锁呢？这里，咱们用两个session来模拟并发，并假设N=9。
你看到了，其实都不须要用到后面的update语句，就已经造成了死锁。咱们按语句执行顺序分析一下：
- Session A执行select...for update语句，因为id=9这一行并不存在，所以会加上间隙锁(5,10);
- Session B执行select...for update语句，一样加上间隙锁(5,10)，间隙锁之间不会冲突，所以这个语句能够执行成功;
- Session B试图插入一行(9,9,9),被Session A的间隙锁挡住了，只好进入等待。
- Session A试图插入一行(9,9,9),被Session B的间隙锁挡住了，死锁。
所以，间隙锁的引入，可能会致使一样的语句锁住更大的范围，这实际上是影响了并发度的。固然，以上的内容都是创建在可重复读隔离级别下的，若是你吧隔离级别更改为读提交，就不会有间隙锁了。但同时，你可能须要解决出现的数据和日志不一致问题。须要把binlog格式设置为row，这也是很多公司使用的配置组合。