拿捏！隔离级别幻读GapLockNextKeyLock

　　前面我写了很多Mysql相关的知识点，到这一篇稍微可以串一下了，从SQL执行流程、MVCC到锁，很多时候可能觉得对于间隙锁和NextKeyLock好像已经理解了，但是好像又觉得理解差那么一点意思，这篇文章从头来梳理一下概念，明确一下这些知识。锁
　　首先，对于Mysql来说实现了两种行级锁：
　　共享锁：允许事务读一行数据，一般记为S，也称为读锁
　　排他锁：允许事务删除或者更新一行数据，一般记为X，也称为写锁
　　关于读写锁的互斥性，应该都很清楚，读锁只能和读锁兼容，其他场景都无法兼容，这里不再赘述吧。
　　隔离级别
　　继续回顾下关于Mysql的4个隔离级别：
　　读未提交ReadUncommitted：能读到其他事务还没有提交的数据，这种现象叫做脏读。
　　读已提交ReadCommitted：只会读取其他事务已经提交的数据，所以不会产生RC的脏读问题。所以又带来一个问题叫做不可重复读，一个事务中两次一样的SQL查询可能查到的结果不一样。
　　可重复读RepeatableRead：RR是Mysql的默认隔离级别，一个事务中两次SQL查询总是会查到一样的结果，不存在不可重复读的问题，但是还是会有幻读的问题。
　　串行Serializable：串行场景没有任何问题，完全串行化的操作，读加读锁，写加写锁。
　　幻读、NextKeyLock、MVCC
　　简单的回顾完了基础，那么我们看看RR级别下还会存在的幻读到底是什么问题，Mysql官方文档这样描述的：
　　Thesocalledphantomproblemoccurswithinatransactionwhenthesamequeryproducesdifferentsetsofrowsatdifferenttimes。Forexample，ifaSELECTisexecutedtwice，butreturnsarowthesecondtimethatwasnotreturnedthefirsttime，therowisaphantomrow。
　　翻译过来就是，幻读指的是同一事务下，不同的时间点，同样的查询，得到不同的行记录的集合。
　　如果说一个select执行了两次，但是第二次比第一次多出来行记录，这就是幻读。
　　所以，对于幻读来说那一定是新增插入的数据！
　　比如说在一个事务内，先查询selectfromuserwhereage10forupdate，得到的结果是id为〔1，2，3〕的记录，再次执行查询，得到了结果为〔1，2，3，4〕的记录，这是幻读。
　　那怎么解决幻读的问题？以前我在文章里说解决幻读的原理是MVCC（MVCC原理看这里）很多网上的文章也有这么写的，其实不能说错，但是肯定也是不太对的，准确地来说应该是通过MVCCNextKeyLock的方式才解决了幻读的问题。
　　对于MVCC中的读可以分为两种，分别叫做快照读和当前读（这个当前读的说法我在书里翻了半天也没有找到，但是看网上一堆资料和大佬都叫当前读，那么我们就叫当前读吧，你知道的话可以告诉我哪本书有这个称呼，Mysql我只看见Lockreading或者锁定读的叫法，有的也说锁定读就是当前读，但是并没有找到当前读这种称呼的出处在哪儿）。
　　快照读就是简单的select查询，查询的都是快照版本，这个场景下因为都是基于MVCC来查询快照的某个版本，所以不会存在幻读的问题，也可以认为是解决了幻读的方案之一，对于RC级别来说，因为每次查询都重新生成一个readview，也就是查询的都是最新的快照数据，所以会可能每次查询到不一样的数据，造成不可重复读，而对于RR级别来说只有第一次的时候生成readview，查询的是事务开始的时候的快照数据，所以就不存在不可重复读的问题，当然就更不可能有幻读的问题了。
　　所以，现在我们说幻读，其实不是指快照读的场景，而是指的是当前读的场景。
　　当前读指的是lockinsharemode、forupdate、insert、update、delete这些需要加锁的操作。对于MVCC来说就是解决的快照读的场景，而对于当前读那么就是NextKeyLock要解决的事情。
　　那么NextKeyLock是什么？怎么解决的幻读？
　　行锁有写锁X和读锁S两种，实际上行锁有3种实现算法，NextKeyLock是其中之一。
　　第一种叫做RecordLock，字面意思，行记录的锁，实际上指的是对索引记录的锁定。
　　比如执行语句selectfromuserwhereage10forupdate，将会锁住user表所有age10的行记录，所有对age10的记录的操作都会被阻塞。
　　第二种都比较熟悉，叫做GapLock，也就是间隙锁，它用于锁定的索引之间的间隙，但是不会包含记录本身。
　　比如语句selectfromuserwhereage1andage10forupdate，将会锁住age在（1，10）的范围区间，此时其他事务对该区间的操作都会被阻塞。
　　间隙锁是可重复读RR隔离级别下特有的，另外还有几种场景也会不使用间隙锁。事务隔离级别设置为不可重复读RC，这样肯定没有间隙锁了。Innodblocksunsafeforbinlog设置为1另外一种情况适用于主键索引或者唯一索引的等值查询条件，比如selectfromuserwhereid1，id是主键索引，这样只使用RecordLock就可以了，因为能唯一锁定一条记录，所以没有必要再加间隙锁了，这是锁降级的过程。
　　而第三种NextKeyLock实际上就是相当于RecordLockGapLock的组合。比如索引有10，20，30几个值，那么被锁住的区间可能会是（，10〕，（10，20〕，（20，30〕，（30，）。解决幻读
　　上一篇关于更新SQL执行过程我们已经对这个基础有了一定的了解，在这里我们去掉和这里内容无关的一些日志的细节，把给数据加锁的流程加入进去，这样通过SQL执行可以更好地理解NextKeyLock到底是如何解决幻读的，执行过程如下：
　　首先第一步Server层会来查询数据存储引擎根据查询条件查到数据之后对数据进行加锁，RecordLock或者间隙锁，然后返回数据Server层拿到数据之后调用API去存储引擎更新数据最后存储引擎返回结果，流程结束
　　搞一张表说明一下，user表有4个字段，id是主键索引，name是唯一索引，age是普通索引，city没有索引，然后插入一些测试数据，下面区分一下几种情况来说明是怎么加NextKeyLock的，然后就知道为啥会没有幻读的问题了。
　　没有索引
　　更新语句updateusersetcitynanjingwherecitywuhan会发生什么？
　　因为city是没有索引的，所以存储引擎只能给所有的记录都加上锁，然后把数据都返回给Server层，然后Server层把city改成nanjing，再更新数据。
　　因此，首先RecordLock会锁住现有的7条记录，间隙锁则会对主键索引的间隙全部加上间隙锁。
　　所以，更新的时候没有索引是非常可怕的一件事情，相当于把整个表都给锁了，那表都给锁了当然不存在幻读了。
　　普通索引
　　我们再假设一个语句selectfromuserwhereage20forupdate。
　　因为age是一个普通索引，存储引擎根据条件过滤查到所有匹配age20的记录，给他们加上写锁，间隙锁会加在（10，20），（20，30）的区间上，因此现在无论怎样都无法插入age20的记录了
　　为什么要锁定这两个区间？如果不锁定这两个区间的话，那么还能插入比如id11，age20或者id21，age20的记录，这样就存在幻读了。
　　（那实际上写锁不光是在会加在age普通索引上，还会加在主键索引上，因为数据都是在主键索引下对吧，这个肯定也要加锁的，为了看起来简单点，就不画出来了）
　　唯一主键索引
　　如果查询的是唯一索引又会发生什么呢？比如有查询语句selectfromuserwherenamebforupdate。
　　上面我们提到过，如果是唯一索引或者主键索引的话，并且是等值查询，实际上会发生锁降级，降级为RecordLock，就不会有间隙锁了。
　　因为主键或者唯一索引能保证值是唯一的，所以也就不需要再增加间隙锁了。
　　很显然，是无法插入nameb的的记录的，也不存在幻读问题。
　　如果是范围查询比如id1andid11呢，实际上也是一样的锁定方式，不再赘述。
　　相比稍微有点不同的是上面也说过，唯一索引不光锁定唯一索引，还会锁定主键索引，主键索引的话只要索引主键索引就行了。
　　总结
　　那最后说了这么多，RR级别下不是都已经解决了幻读的问题吗，怎么还说有幻读的问题呢？
　　关于这个问题，可以看看这个报出的BUGhttps：bugs。mysql。combug。php？id63870，回复说了这不是BUG，这是符合隔离规范的设计，有兴趣的自己看看吧。