众所周知，Mysql在InnoDB下有四种隔离级别：
创新互联主要从事成都网站制作、成都网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务潮安,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108
未提交读（Read Uncommitted）
提交后读（Read Committed）
可重复读（Repeatable Read）
串行化（Serializable）
其中可重复读（RR）可以避免脏读（ a事务读到b事务回滚前的数据）以及可不重复读（ a事务在b事务修改提交的前后，两次分别读到的数据不一致）。但是对于幻读（a事务在b事务insert提交前后，两次分别读到的数据不一致），却存在争议。
下面我们来做一个试验：
对于下面这张简单的数据表
id num
1 11
2 22
3 33
我们开启a、b两个事务
a事务 b事务
begin begin
select * from tb ----
---- insert into tb (id,num)values(4,44)
---- commit
select * from tb ----
commit
试验结果：a事务的两次select查询到的结果相同，在后一次查询中没有返回新插入id=4的那条记录。
据此，很多人判断说RR隔离级别下“不存在”幻读。
但果真如此吗？----
出现上面的试验结果，是因为在RR隔离级别事务下，Mysql会对前一次select的结果快照。所以第二次select其实是快照读（这也正是RR隔离级别下能够避免不可重复读的策略）。
如果我们把试验条件稍作修改，同样开启a、b两个事务：
a事务 b事务
begin begin
select * from tb ----
---- insert into tb (id,num)values(5,55)
---- commit
update tb set num=num+1 ---- #此处a事务做一次修改操作
select * from tb ----
commit
试验结果：在a事务的第二次select中出现了b事务新插入的id=5的记录。
由于做了update操作，之前的快照失效了，所以说RR隔离级别下的快照策略并没能真正避免幻读。
ps. 假如给第二次的select查询上锁（无论是共享锁还是排它锁），也会得到同样的结果，都会令快照失效。
原因:
(1)在rc隔离级别下,事务没有gap lock锁,因此可以在小于等于5的范围内插入一条新记录。
(2)binlog为statement记录的是master上产生的sql语句,按提交顺序记录的,因此binlog中记录的是先插入数据,后删除数据。(虽然master上是先删除数据后插入数据),逻辑上产生了不一致。
如何解决:
只需要解决上述问题中的一个就能保证数据的同步了。
(1)可以使用rr隔离级别;
(2)使用row格式的binlog;
mysql 为并发事务同时对一条记录进行读写时，提出了两种解决方案：
1）使用 mvcc 的方法，实现多事务的并发读写，但是这种读只是“快照读”，一般读的是历史版本数据，还有一种是“当前读”，一般加锁实现“当前读”，或者 insert、update、delete 也是当前读。
2）使用加锁的方法，锁分为共享锁（读锁），排他锁（写锁）
快照读：就是select
当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
mysql 在 RR 级别怎么处理幻读的呢？一般来说，RR 级别通过 mvcc 机制，保证读到低于后面事务的数据。但是 select for update 不会触发 mvcc，它是当前读。如果后面事务插入数据并提交，那么在 RR 级别就会读到插入的数据。所以，mysql 使用 行锁 + gap 锁（简称 next-key 锁）来防止当前读的时候插入。
Gap Lock在InnoDB的唯一作用就是防止其他事务的插入操作，以此防止幻读的发生。
Innodb自动使用间隙锁的条件：
最近在网上看了不少mysql锁的文章，不少文章都提到InnoDB的RR隔离级别（Repeatable Read）无法解决幻读的问题。对此问题作者亲自做了一些实验，将实验结论记录在此。
本次实验的mysql版本为5.7.22 。
此篇文章的重点在于通过实验的形式解释清楚InnoDB的RR隔离级别是否解决了幻读问题。所以文中将不会对一些相关的概念进行解释，默认读者已经具备相关知识。如果读者对于以下的知识点不甚清楚，最好自行查阅相关资料，理解清楚之后再阅读接下来的实验内容，以免造成困惑。
进行此次实验需要具备的知识点（包括但不限于）：
创建表结构：
创建两条数据：
最终的表数据如下：
打开两个终端，连上mysql，分别启动事务a和事务b。
在事务a和事务b上面分别执行如下命令：
查询出来的结果如下：
事务a：
事务b:
很明显事务b没有查询到事务a未提交的新插入数据。原因也很简单，因为 普通的select语句是快照读，而事务b启动时，它的快照数据就已经被版本锁定了 。
那么我们在事务b里面执行如下命令来看看执行结果：
执行完成之后我们发现事务b此时会block住，原因是 事务a的insert语句排它锁住了id为3的新插入数据，而事务b想请求所有行的共享锁，肯定是需要等待的。
那么此时事务b当前读id为1或2的数据（非事务a新插入数据）是否可行呢？
结论是可行的，因为 tmp_table 存在唯一键，且事务a的insert语句只是锁住了id为3的行。所以其他事务获取其他行的共享锁是可行的 。读者可以自行测试，这里就不做演示了。
事务a和事务b执行如下命令：
事务b打印的结果：
还是一样， 因为普通select是快照读，事务b还是读取到的是快照数据，所以不包含事务a提交之后的新数据 。
让我们在事务b下面使用共享锁查看当前版本数据：
结果如下：
可以查询到事务a已提交的新数据，所以此时使用当前读就产生了幻读 。
还有另一种情况也会产生幻读，并且只需要执行普通的select语句。下面请看演示。
在事务b下面执行如下两条语句：
第一条命令使用update更新了事务a已提交的新数据，第二条命令通过普通的select语句查看快照数据。
打印结果如下：
可以看到事务a已提交的新数据被事务b使用update语句更新了，并且通过普通的select语句给查询出来了，很显然，出现了幻读 。
所以说InnoDB的RR隔离级别没有或者解决了幻读问题都不太准确。应该说它并没有完全解决幻读的问题。
如果在同一个事务里面，只是总是执行普通的select快照读，是不会产生幻读的。
但是如果在这个事务里面通过当前读或者先更新然后快照读的形式来读取数据，就会产生幻读。
Phantom Rows
Innodb 中 RR 隔离级别能否防止幻读？
