1、隔离级别

为什么mysql默认使用RR；

级别太高会影响并发度，太低会出现脏读现象；
最重要的是主从同步的问题；
当binlog的格式为statement时，binlog 里面记录的就是 SQL 语句的原文
为了兼容历史上的那种statement格式的bin log。
在RC情况下，主库因为隔离级别没有问题，但是从库会发生数据不一致的问题；
在RR中不会出现这种问题，是因为在其中存在间隙锁和临建锁，确保一个事务提交以后才能执行下一个事务；

2、RR和RC区别

只有这两个才会使用快照读；
在 RC 中，每次读取都会重新生成一个快照，总是读取行的最新版本

在数据库的 RC 这种隔离级别中，还支持”半一致读” ，一条update语句，如果 where 条件匹配到的记录已经加锁，那么InnoDB会返回记录最近提交的版本，由MySQL上层判断此是否需要真的加锁。

在 RC 中，只会对索引增加Record Lock，不会添加Gap Lock和Next-Key Lock。
在 RR 中，为了解决幻读的问题，在支持Record Lock的同时，还支持Gap Lock和Next-Key Lock；
所以 RC并发更好，减少锁的问题；

在RC 中读取到别的事务修改的值其实问题不太大的，只要修改的时候的不基于错误数据就可以了，所以我们都是在核心表中增加乐观锁标记，更新的时候都要带上锁标记进行乐观锁更新

Innodb的RR到底有没有解决幻读？

间隙锁解决了部分当前读的幻读问题；
MVCC解决了快照读的幻读问题；

MVCC

时机
在 RC 中，每次读取都会重新生成一个快照，总是读取行的最新版本。
在 RR 中，快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照。

在同一个事务里面，如果既有快照读，又有当前读，那是会产生幻读的

MVCC只是解决了快照读中的欢度问题，但是对于当前读还是会有幻读的问题；
在RR中，如果本事务中发生了数据的修改，那么就会更新快照，那么最后一次查询的结果也就发生了变化。

间隙锁是导致死锁的一个重要原因

MVCC理解

并发问题：MVCC解决是读-写并发的问题；

快照读是MVCC实现的基础，而当前读是悲观锁实现的基础。

undo log是Mysql中比较重要的事务日志之一，顾名思义，undo log是一种用于回退的日志，在事务没提交之前，MySQL会先记录更新前的数据到 undo log日志文件里面，当事务回滚时或者数据库崩溃时，可以利用 undo log来进行回退。
针对一条记录的多个快照，通过隐藏主键+回滚指针生成一个快照链表
Read View 主要来帮我们解决可见性的问题的, 即他会来告诉我们本次事务应该看到哪个快照，不应该看到哪个快照。