【60期】事务隔离级别中的可重复读能防幻读吗?（MySQL面试第二弹）
面试刷图，查缺补漏
前言
每次谈到数据库的事务隔离级别，大家一定会看到这张表。
其中，可重复读这个隔离级别，有效地防止了脏读和不可重复读，但仍然可能发生幻读，可能发生幻读就表示可重复读这个隔离级别防不住幻读吗?
我们的数据库中有如下结构和数据的Users表，下文中我们将对这张表进行操作
长文预警，读完此篇文章，大概需要您二十至三十分钟。
什么是幻读?
脏读
当一个事务读取到另外一个事务修改但未提交的数据时，就可能发生脏读。
在我们的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。
现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了，所以这条数据就是脏读。
不可重复读
“不可重复读”现象发生在当执行SELECT 操作时没有获得读锁或者SELECT操作执行完后马上释放了读锁；另外一个事务对数据进行了更新，读到了不同的结果。
幻读
“幻读”又叫"幻象读",是''不可重复读''的一种特殊场景：当事务1两次执行''SELECT ... WHERE''检索一定范围内数据的操作中间，事务2在这个表中创建了(如[[INSERT]])了一行新数据，这条新数据正好满足事务1的“WHERE”子句。
三者到底什么区别
脏读：指读到了其他事务未提交的数据。
不可重复读：读到了其他事务已提交的数据(update)。
不可重复读与幻读都是读到其他事务已提交的数据,但是它们针对点不同。
不可重复读：update。
MySQL中的四种事务隔离级别
未提交读
把脏读的图拿来分析分析，因为事务2更新id=1的数据后，仍然允许事务1读取该条数据,所以事务1第二次执行查询，读到了事务2更新的结果，产生了脏读。
已提交读
SET session transaction isolation level read committed;SET SESSION binlog_format = 'ROW';（或者是MIXED）
在已提交读（READ COMMITTED）级别中，读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行，会对该写锁一直保持直到到事务提交。
同样，我们来分析脏读，事务2更新id=1的数据后，在提交前，会对该对象写锁，所以事务1读取id=1的数据时，会一直等待事务2结束，处于阻塞状态，避免了产生脏读。
同样，来分析不可重复读，事务1读取id=1的数据后并没有锁住该数据，所以事务2能对这条数据进行更新，事务2对更新并提交后，该数据立即生效，所以事务1再次执行同样的查询，查询到的结果便与第一次查到的不同，所以已提交读防不了不可重复读。
可重复读
在可重复读（REPEATABLE READS）是介于已提交读和可串行化之间的一种隔离级别(废话😅)，它是InnoDb的默认隔离级别，它是我这篇文章的重点讨论对象，所以在这里我先卖个关子,后面我会详细介绍。
可串行化
可串行化（Serializable ）是高的隔离级别，它求在选定对象上的读锁和写锁保持直到事务结束后才能释放，所以能防住上诉所有问题，但因为是串行化的，所以效率较低。
可重复读（Repeatable read）能防住幻读吗?
可重复读
在讲可重复读之前，我们先在mysql的InnoDB下做下面的实验。
可以看到，事务A既没有读到事务B更新的数据，也没有读到事务C添加的数据，所以在这个场景下，它既防住了不可重复读，也防住了幻读。
到此为止，相信大家已经知道答案了，这是怎么做到的呢?
悲观锁与乐观锁
我来介绍一下悲观锁和乐观锁。
悲观锁
乐观锁
MySQL、ORACLE、PostgreSQL等都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免不可重复读和幻读,MVCC的实现没有固定的规范，每个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。
MVCC(多版本并发控制)
-
SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。 -
INSERT时，保存当前事务版本号为行的创建版本号 -
DELETE时，保存当前事务版本号为行的删除版本号 -
UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行
通过MVCC，虽然每行记录都要额外的存储空间来记录version，需要更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多读操作都不用加锁，读取数据操作简单，性能好。
MCVV这种读取历史数据的方式称为快照读(snapshot read)，而读取数据库当前版本数据的方式，叫当前读(current read)。
快照读
我们平时只用使用select就是快照读，这样可以减少加锁所带来的开销。
select * from table ....当前读
以下第一个语句需要加共享锁，其它都需要加排它锁。
select * from table where ? lock in share mode;select * from table where ? for update;insert;update;delete;
可以看到在读提交的隔离级别中，事务1修改了所有class_id=1的数据，当时当事务2 insert后，事务A莫名奇妙地多了一行class_id=1的数据，而且没有被之前的update所修改，产生了读提交下的的幻读。
还是那句话，Mysql已经是个成熟的数据库了，怎么会采用如此低效的方法呢？其实这里的锁，是通过next-key锁实现的。
Next-Key锁
前往学习: https://www.cnblogs.com/sujing/p/11110292.html
B+树的特点是所有数据都存储在叶子节点上，以非聚簇索引的秦寿生为例，在秦寿生的右叶子节点存储着所有秦寿生对应的Id，即图中的34。
马失前蹄
比如如下的例子:
2. a事务再select出来的结果在MVCC下还和第一次select一样
3. 接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的）
MySQL 5.6 Reference Manual
understanding InnoDB transaction isolation levels
MySQL · 源码分析 · InnoDB Repeatable Read隔离级别之大不同
不懂数据库索引的底层原理？那是因为你心里没点b树
Innodb中的事务隔离级别和锁的关系
MySQL InnoDB中的行锁 Next-Key Lock消除幻读
来源：cnblogs.com/CoderAyu/p/11525408.html
最近五期