和RC模式不同，RR模式下事务不会再每次执行select的时候生成最新的read_view，而是在事务第一次select时就生成read_view，后续不会再变更，直至当前事务结束。这样可以有效避免不可重复读，使得当前事务在整个事务过程中读到的数据都保持一致。示意图如下所示：
这个就很容易理解，三次查询所使用的全局活跃事务列表都一样，且都是第一次生成的read_view，那之后查到的记录必然和第一次查到的记录一致。
RR隔离级别能够避免幻读吗？如果对幻读还不���解的话，可以参考该系列的第一篇文章。如下图所示，1号事务对针对id>1的过滤条件执行了三次查询，2号事务执行了一次插入，插入的记录刚好符合id>1这个条件。可以看出来，三次查询得到的数据是一致的，这个是由RR隔离级别的MVCC机制保证的。这么看来，是避免了幻读，但是在最后1号事务在id=2处插入一条记录，MySQL会返回Duplicate entry的错误，可见避免了幻读是一种假象。
之前提到的所有RR级别的select语句我们称为快照读，快照读能够保证不可重复读，但并不能避免幻读。于是MySQL又提出”当前读”的概念，常见的当前读语句有：
1. select for update
2. select lock in share mode
3. update / delete
并且规定，RR级别下当前读语句会给记录加上一种特殊的锁－Gap锁，Gap锁并不锁定某个具体的记录，而是锁定记录与记录之间的间隔，保证这个间隔中不会插入新的其他记录。下图是一个示意图：
上图中1号事务首先执行了一个当前读的select语句，这个语句会在 id > 0的所有间隔加上Gap锁，接下来2号事务在id = 3处执行插入时系统就会返回Lock wait timeout execcded的异常。当然，其他事务可以在id <= 0的条件下插入成功，这没问题。
Serializable （技术解读：S锁(读)＋X锁(写)）Serialization隔离级别是最严格的隔离级别，所有读请求都会加上读锁，不分快照读和当前读，所有写会加上写锁。当然，这种隔离级别的性能因为锁开销而相对最差。
MySQL事务持久性保证MySQL事务持久化策略和HBase基本相同，但是涉及的组件相对比较多，主要有doublewrite、redo log以及binlog：
1. MySQL数据持久化（DoubleWrite）
实际上MySQL的真实数据写入分为两次写入，一次写入到一个称为DoubleWrite的地方，写成功之后再真实写入数据所在磁盘。为什么要写两次？这是因为MySQL数据页大小与磁盘一次原子操作大小不一致，有可能会出现部分写入的情况，比如默认InnoDB数据页大小为16K，而磁盘一次原子写入大小为512字节（扇区大小），这样一个数据页写入需要多次IO，这样一旦中间发生异常就会出现数据丢失。另外需要注意的是DoubleWrite性能并不会影响太大，因为写入DoubleWrite是顺序写入，对性能影响来说不是很大。
2. redolog持久化策略（innodb_flush_log_at_trx_commit）
redolog是InnoDB的WAL，数据先写入redolog并落盘，再写入更新到bufferpool。redolog的持久化策略和HBase中hlog的持久化策略一致，默认为1，表示每次事务提交之后log就会持久化到磁盘；该值为0表示每隔1秒钟左右由异步线程持久化到磁盘，这种情况下MySQL发生宕机有可能会丢失部分数据。该值为2表示每次事务提交之后log会flush到操作系统缓冲区，再由操作系统异步flush到磁盘，这种情况下MySQL发生宕机不会丢失数据，但机器宕机有可能会丢失部分数据。
3. binlog持久化策略（sync_binlog）
binlog作为Server层的日志系统，主要以events的形式顺序纪录了数据库的各种操作，同时可以纪录每次操作所花费的时间。在MySQL官方文档上，主要介绍了Binlog的两个最基本核心作用：备份和复制，因此binlog的持久化会一定程度影响数据备份和复制的完整性。和redo持久化策略相同，可取值有0，1，N。默认为0，表示写入操作系统缓冲区，异步flush到磁盘。该值为1表示同步写入磁盘。为N则表示每写N次操作系统缓冲就执行一次刷新操作。