我们不管从数据库方面的教课书中学到，还是从网络上看到，大都是上文中事务的四种隔离级别这一模块列出的意思，RR级别是可重复读的，但无法解决幻读，而只有在Serializable级别才能解决幻读。于是我加了一个事务C来展示效果。在事务C中添加了一条teacher_id=1的数据commit，RR级别中应该会有幻读现象，事务A在查询teacher_id=1的数据时会读到事务C新加的数据。但是测试后发现，在MySQL中是不存在这种情况的，在事务C提交后，事务A还是不会读到这条数据。可见在MySQL的RR级别中，是解决了幻读的读问题的。参见下图
　　MySQL的Innodb中的事务隔离级别和锁的关系
　　读问题解决了，根据MVCC的定义，并发提交数据时会出现冲突，那么冲突时如何解决呢？我们再来看看InnoDB中RR级别对于写数据的处理。
　　####“读”与“读”的区别
　　可能有读者会疑惑，事务的隔离级别其实都是对于读数据的定义，但到了这里，被拆成了读和写两个模块来讲解。这主要是因为MySQL中的读，和事务隔离级别中的读，是不一样的。
　　我们且看，在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！这在一些对于数据的时效特别敏感的业务中，很可能出问题。
　　对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：
　　快照读：是select select * from table ....; 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。 select * from table where ? lock in share mode;select * from table where ? for update;insert;update ;delete;
　　事务的隔离级别实际上都是定义了当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。而update、insert这些“当前读”，需要另外的模块来解决了。
　　###写（"当前读"）
　　事务的隔离级别中虽然只定义了读数据的要求，实际上这也可以说是写数据的要求。上文的“读”，实际是讲的快照读；而这里说的“写”是当前读了。
　　为了解决当前读中的幻读问题，MySQL事务使用了Next-Key锁。
　　####Next-Key锁
　　Next-Key锁是行锁和GAP（间隙锁）的合并，行锁上文已经介绍了，接下来说下GAP间隙锁。
　　行锁可以防止不同事务版本的数据修改提交时造成数据冲突的情况。但如何避免别的事务插入数据成了问题。我们可以看看RR级别和RC级别的对比
　　RC级别：
　　事务A 事务B begin;
　　begin;
　　select id，class_name，teacher_id from class_teacher where teacher_id=30;
　　id class_name teacher_id 2 初三二班 30
　　update class_teacher set class_name='初三四班' where teacher_id=30;
　　insert into class_teacher values (null，'初三二班'，30);
　　commit;
　　select id，class_name，teacher_id from class_teacher where teacher_id=30;
　　id class_name teacher_id 2 初三四班 30 10 初三二班 30
　　RR级别：
　　事务A 事务B begin;
　　begin;
　　select id，class_name，teacher_id from class_teacher where teacher_id=30;
　　id class_name teacher_id 2 初三二班 30 update class_teacher set class_name='初三四班' where teacher_id=30;
　　insert into class_teacher values (null，'初三二班'，30);
　　waiting....
　　select id，class_name，teacher_id from class_teacher where teacher_id=30;
　　id class_name teacher_id 2 初三四班 30 commit; 事务Acommit后，事务B的insert执行。
　　通过对比我们可以发现，在RC级别中，事务A修改了所有teacher_id=30的数据，但是当事务Binsert进新数据后，事务A发现莫名其妙多了一行teacher_id=30的数据，而且没有被之前的update语句所修改，这是“当前读”的幻读。
　　RR级别中，事务A在update后加锁，事务B无法插入新数据，这样事务A在update前后读的数据保持一致，避免了幻读。这个锁，是Gap锁。
　　MySQL是这么实现的：
　　在class_teacher这张表中，teacher_id是个索引，那么它会维护一套B+树的数据关系，为了简化，我们用链表结构来表达（实际上是个树形结构，但原理相同）
　　MySQL的Innodb中的事务隔离级别和锁的关系
　　如图所示，InnoDB使用的是聚集索引，teacher_id身为二级索引，要维护一个索引字段和主键id的树状结构（这里用链表形式表现），并保持顺序排列。
　　Innodb将这段数据分成几个个区间
　　(negative infinity， 5]，(5，30]，(30，positive infinity)；
　　update class_teacher set class_name='初三四班' where teacher_id=30;不仅用行锁，锁住了相应的数据行；同时也在两边的区间，（5，30]和（30，positive infinity），都加入了gap锁。这样事务B无法在这个两个区间insert进新数据。
　　受限于这种实现方式，Innodb很多时候会锁住不需要锁的区间。如下所示：
　　事务A 事务B 事务C begin; begin; begin;
　　select id，class_name，teacher_id from class_teacher;
　　id class_name teacher_id 1 初三一班
　　5
　　2 初三二班 30 update class_teacher set class_name='初一一班' where teacher_id=20;
　　insert into class_teacher values (null，'初三五班'，10);
　　waiting .....
　　insert into class_teacher values (null，'初三五班'，40); commit; 事务A commit之后，这条语句才插入成功 commit; commit;
　　update的teacher_id=20是在(5，30]区间，即使没有修改任何数据，Innodb也会在这个区间加gap锁，而其它区间不会影响，事务C正常插入。
　　如果使用的是没有索引的字段，比如update class_teacher set teacher_id=7 where class_name='初三八班（即使没有匹配到任何数据）'，那么会给全表加入gap锁。同时，它不能像上文中行锁一样经过MySQL Server过滤自动解除不满足条件的锁，因为没有索引，则这些字段也没有排序，也没有区间。除非该事务提交，否则其它事务无法插入任何数据。
　　行锁防止别的事务修改或删除，GAP锁防止别的事务新增，行锁和GAP锁结合形成的的Next-Key锁共同解决了RR级别在写数据时的幻读问题。
　　###Serializable
　　这个级别很简单，读加共享锁，写加排他锁，读写互斥。使用的悲观锁的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发的特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。
　　这里要吐槽一句，不要看到select说不会加锁了，在Serializable这个级别，还是会加锁的！