在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解决幻读的代价。