“幻读”：
在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在“当前读”下才会出现。
修改结果，被之后的 select 语句用“当前读”看到，也不能称为幻读。幻读仅专指“新插入的行”。
查询加了 for update，都是当前读。而当前读的规则，就是要能读到所有已经提交的记录的最新值。
幻读有什么问题？
首先，是语义上的。这个语义被破坏了
其次，是数据一致性的问题。
我们知道，锁的设计是为了保证数据的一致性。而这个一致性，不止是数据库内部数据状态在此刻的一致性，还包含了数据和日志在逻辑上的一致性。语句序列不论是拿到备库去执行，还是以后用 binlog 来克隆一个库，都可能存在问题。
这个数据不一致到底怎么改？
1）把扫描过程中碰到的行，也都加上写锁。修改记录的情况是能解决了，即使把所有的记录都加上锁，还是阻止不了新插入的记录。
2）为了解决幻读问题，InnoDB 引入新的锁，也就是间隙锁 (Gap Lock)。
在一行行扫描的过程中，不仅将给行加上了行锁，还给行两边的空隙，也加上了间隙锁。数据行是可以加上锁的实体，数据行之间的间隙，也是可以加上锁的实体。但是间隙锁跟我们之前碰到过的锁都不太一样。
跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个操作。间隙锁之间都不存在冲突关系。
间隙锁和行锁合称 next-key lock，每个 next-key lock 是前开后闭区间。
间隙锁的引入，可能会导致同样的语句锁住更大的范围，这其实是影响了并发度的。
解决方案：
问题都是在可重复读隔离级别下的，间隙锁是在可重复读隔离级别下才会生效的。
所以如果把隔离级别设置为读提交的话，就没有间隙锁了。但同时，你要解决可能出现的数据和日志不一致问题，需要把 binlog 格式设置为 row。
这也是现在不少公司使用的配置组合。
