innodb下幻读是如何在RR级别下被解决的？

先来简单的复习一下数据库隔离级别

1. RU(Read Uncommitted)

一个事务A读取到另一个事务B未提交的修改，B回滚了，就造成了数据不一致。（现象：脏读）

1. RC(Read Committed)

一个事务A在事务执行过程中第一次读取的值和第二次读取的值不一致，这是由于事务B在俩次读取之间修改了数据并提交了事务。（现象：不可重复读）

1. RR(Repeatable Read)

一个事务A在事务执行过程中第一次读取的值和第二次读取的值一致（解决了不可重复读），但是其他事务B 的insert 或者 delete的操作，会影响到俩次查询的条数（现象：幻读）

1. Serializable

最高的事务隔离级别，串行化。

问题来了：RR下会出现幻读，那为什么innodb能在RR下解决幻读呢？不是互相矛盾吗？

解释：这是由于innodb和标准不一致导致的。具体可以看看github火热的讨论Innodb RR 下能否防止幻读?

结论：RR 下，innodb下的幻读是由MVCC 或者 GAP 锁 或者是next-key lock 解决的。

关于MVCC 可以查看这篇文章 MVCC原理

意思就是MVCC判断了记录的可见性，比如 select count(*) from table where col_name = xxx 时(属于快照读)，在RR 级别下，这条事务在事务一开始就生成了readview，通过这个readview 这条语句将会找到符合条件的行并且计算数量。 那么关于与如何找到这些符合条件的行，满足where 条件的同时也得满足本事务对这些行的可见性。 所以在同一事务里并不会产生幻读的现象。

关于GAP 锁 可以查看这篇文章next-key lock

在这里我们需要了解 当前读 和 快照读 的区别

1. 快照读：简单的select操作，属于快照读，不加锁。 select * from table where ?;
   
2. 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。
   select * from table where ? lock in share mode;
   select * from table where ? for update;
   insert into table values (…);
   update table set ? where ?;
   delete from table where ?;
   
   所有以上的语句，都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。
   

我们来以下倆段伪代码：

//code 1
beginTransaction
delete * from table where id = ?  （加了二级索引（不是唯一索引））
endTransaction
//code 2
beginTransaction
select count(*) from table where id = ? for update （加了二级索引（不是唯一索引））
endTransaction
复制代码

1. code 1 的分析：
   由于delete * from table where id = ? 这是当前读，它会锁定一个范围采用GAP 锁的方式，让符合条件的范围内不得让其他事务插入数据，这样也就解决了幻读。
2. code 2 的分析：
   由于select count(*) from table where id = ? for update 虽然也是当前读，但是它加的锁是next-key-lock，它是由GAP锁和record锁组成的，所以它也能锁定范围不让其它事务插入符合条件的数据，锁定记录本身，也不让其它事务修改数据。这样也就避免了幻读