在MYSQL的RR隔离级别下， MYSQL也解决了幻读的问题。 主要是依靠两个特性解决的， 一个是MVCC（一致性快照） 一个是间隙锁。
MVCC如何解决幻读
begin
select count(*) from table where id >10
...... 一系列的其他操作 ......
select count(*) from table where id >10
commit
上面的sql 语句如果在执行的过程中（中间的一系列操作中）， 其他的事务新增了 id>10 的记录， 这个sql语句的前后两次查询记录的条数的结果还是一样的。
为何会这样是因为MYSQL的MVCC机制， 在事务开始的时候， 其实已经创建了一个快照， 后面的所有查询都是查询这个快照的， 所以查询结果一样，
至于MVCC的机制是如何作用的， MYSQL主要是记住各个事务的id， 并根据每行数据的事务id来进行比较来确定版本快照的， 具体机制大家可以搜下。
如果我们把语句改成这样呢？
begin
select count(*) from table where id >10 for update
...... 一系列的其他操作 ......
select count(*) from table where id >10 for update
commit
由于for update 的特性导致这个查询语句是使用的当前读， 并没有使用快照。 那么快照就不能保证解决幻读问题了。 这个时候就要用上间隙锁的概念了。
间隙锁保证幻读正确
begin
select count(*) from table where id >10 for update ## 10前面的一条记录的id就是9
...... 一系列的其他操作 ......
select count(*) from table where id >10 for update
commit
这个sql的事务在执行到第一个查询语句的时候， 会加上间隙锁的， 锁住的范围是（9，+无穷] . 那么其他的事务无法再这个id范围进行任何的修改和插入操作了， 他们如果要操作就会堵住。
这样mysql又通过间隙锁的功能解决了幻读问题，但是可以看到这个代价很大的， 仅次于全表写锁了。
间隙锁的死锁问题
正常的读写锁之间的互斥关系我们很清楚，但是间隙锁呢， 间隙锁与间隙锁之间是不互斥的。 就是一个事务A锁住了（0，100]的间隙锁，那么B事务也可以重复获取（0，100]的间隙锁。
上面两个事务都获取了间隙锁， 这个时候如果A事务要在这个间隙之间插入一条记录，会阻塞，因为B事务间隙锁了， 同样B事务也不能操作这个间隙了。 这样就导致了两个线程形成死锁了。
这就是代价，是InnoDB解决幻读的代价。