问题：mysql innodb RR隔离级别下是否可以防止幻读？
今天面试被问到了这个问题，由于自己还没有系统的学习过mysql，遇到问题总会一知半解，因此对这个问题的理解不是很清晰，今天通过读文章和跟同事讨论，先得出个一般的结论。后续还是的踏实的看看书啊。
另外面试官提到开启一个参数能够解决幻读的问题，虽然没有给答案，我猜测应该他说的是这个innodb_locks_unsafe_for_binlog。
参考文章里面有比较经典的美团技术博客的文章，书籍、文章也得常看常新，要细细琢磨。
参考文章：
什么是幻读？
如果使用锁机制来实现这两种隔离级别，在可重复读中，该sql第一次读取到数据后，就将这些数据加锁，其它事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以当事务A先前读取了数据，或者修改了全部数据，事务B还是可以insert数据提交，这时事务A就会发现莫名其妙多了一条之前没有的数据，这就是幻读，不能通过行锁来避免
解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据，本事务再更新时，就会“惊奇的”发现了这些新数据，貌似之前读到的数据是“鬼影”一样的幻觉。
我理解：只限于数据库中关于事务隔离级别定义，由于事务锁不了插入操作，后续查询或者更新的时候像出现了幻觉一样，无形中多了别的事务已经commit insert的一条记录。
innodb rr模式下，避免了吗？先说自己的结论：
mysql innodb RR隔离级别下，也不能完全防止幻读问题的发生。如果防止幻读，在涉及到业务需要防止幻读的时候，必须开启锁（不管是共享锁还是排他锁）。----你真的有这个应用场景的话
小问题补充
- 1 首先是innodb_locks_unsafe_for_binlog这个参数，代表是否禁用间隙锁，默认是off的，即开启间隙锁。
- 2 mysql innodb rr级别情况下，并且innodb_locks_unsafe_for_binlog参数是关闭的，能够解决幻读的场景。
具体可以去看参考文章1和2，里面对解决的问题做了细致的分析，这里给出结论如下：- 2.1 mysql提出的当前读和快照读的概念。
- 快照读：就是普通的select
select * from table ….;- 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert;
update ;
delete;
- 2.2 对于快照读的场景，通过mvcc版本管理来解决幻读的问题。就是a事务只做了两次查询操作，两次查询中间即使有符合条件的插入，第二次查询的结果也是原来的数据信息。
mvcc版本管理的具体意思如下（有的文章说底层是通过redo和undo日志搞定的，不纠结，以后看。）：
在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下：
- SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
- INSERT时，保存当前事务版本号为行的创建版本号
- DELETE时，保存当前事务版本号为行的删除版本号
- UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行
这里面感觉有个前提是a事务的版本号比那个插入事务的版本号要小。
-
2.3 针对当前读的情况，mysql是通过Next-Key锁搞定的。就是再当前读的情况下，会加入一个范围锁，锁住一个区间，区间内如果有别的事务进行插入操作，是要等待当前事务提交的。
-
2.4 搞不定的场景。假设事务a先进行了一次范围查询操作，由于是普通的查询，并没有开始间隙锁，也就说允许其他事务在查询的范围内进行插入的，假设这个时候其他事务插入并提交，那么a事务如果进行更新操作，那就会把插入的数据也更新了。
我感觉哈，其实2.4经常是我们写代码里面面临的场景，我们一般写代码的时候经常会select一堆数据，完了内存里面判断，完了去更新数据。如果以后写的过程中遇到这种场景的话，一定要注意了。
-
2.5 其实真的写代码的时候，锁的范围一定要小要小，尽量别搞gap锁。
-
2.6 待确认的问题：MVCC机制与redo、undo日志的关系；gap间隙锁怎么加区间的？
以上都没有经过实践验证，纯理论推导。
