为什么MySQL默认使用RR隔离级别？
对于数据库的默认隔离级别，Oracle默认的隔离级别是 RC，而MySQL默认的隔离级别是 RR。
那么，你知道为什么Oracle选择RC作为默认级别，而MySQL要选择RR作为默认的隔离级别吗？
Oracle的隔离级别
Oracle支持ANSI/ISO SQL定义的Serializable和Read Committed两种隔离级别，根据Oracle官方文档的介绍，Oracle的隔离级别包括Read Committed、Serializable和Read-Only。
图片
Read-Only的隔离级别类似于Serializable，然而仅允许只读事务进行数据检索，不允许在事务中修改数据，除非使用者是SYS用户。
在Oracle的这三种隔离级别中，显而易见，Serializable和Read-Only都不适合作为默认隔离级别，因此唯一的选择就是Read Committed了。
MySQL的隔离级别
与Oracle相比，MySQL提供的默认隔离级别范围更加广泛。
首先，我们排除了Serializable和Read Uncommitted这两种级别，原因是一个隔离级别过高会影响并发度，另一个过低则存在脏读问题。
剩下的RR和RC两种，如何选择呢？
MySQL在设计之初就旨在提供一个稳定的关系型数据库。为解决MySQL单点故障问题，MySQL采取了主从复制机制。
所谓的主从复制，即通过建立MySQL集群，以整体向外提供服务。集群内的机器分为主服务器（Master）和从服务器（Slave），主服务器负责提供写服务，而从服务器则提供读服务。
在MySQL主从复制过程中，数据的同步通过binlog进行。简单来说，主服务器将数据变更记录到binlog中，然后将binlog同步传输给从服务器。从服务器接收到binlog后，将其中的数据恢复到自己的数据库存储中。
那么，binlog里记录的究竟是什么内容？它的格式又是怎样的呢？
MySQL的binlog主要支持三种格式，即statement、row和mixed。MySQL从5.1.5版本开始支持row格式，在5.1.8版本中开始支持mixed格式。
statement和row之间最重要的区别在于，当binlog的格式为statement时，binlog记录的是SQL语句的原文。
由于MySQL早期仅支持statement这一种binlog格式，因此在使用提交读（Read Committed）和未提交读（Read Uncommitted）这两种隔离级别时都可能会出现问题。
举个例子，有一个数据库表t1，表中有如下两条记录：
CREATE TABLE `t1` (
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
KEY `b` (`b`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
insert into t1 values(10,1);
接着开始执行两个事务的写操作：
|
Session 1 |
Session 2 |
|
set session transaction isolation level read committed; |
|
|
set autocommit = 0; |
set session transaction isolation level read committed; |
|
begin; |
begin; |
|
delete from t1 where b < 100; |
|
|
|
insert into t1 values(10,99); |
|
|
commit; |
|
commit; |
|
以上两个事务执行之后，数据库里面的记录会只有一条记录（10,99），这个发生在主库的数据变更大家都能理解。
即使 Session 1 的删除操作在 Session 2 的插入操作之后提交，由于 READ COMMITTED 的隔离级别，Session 2 的插入操作不会看到 Session 1 的删除操作，所以最后数据库中仍然会留下 Session 2 插入的记录 (10,99)。
这种行为是 READ COMMITTED 隔禽级别的一种特性，它会在事务开始时创建一个快照。确保事务之间的隔离性，避免了数据不一致性的问题。
以上两个事务执行之后，会在bin log中记录两条记录，因为事务2先提交，所以insert into t1 values(10,99);会被优先记录，然后再记录delete from t1 where b < 100;（再次提醒：statement格式的bin log记录的是SQL语句的原文）
这样bin log同步到备库之后，SQL语句回放时，会先执行insert into t1 values(10,99);，再执行delete from t1 where b < 100;。
这时候，数据库中的数据就会变成 EMPTY SET，即没有任何数据。这就导致主库和备库的数据不一致了！！！
为了解决这种问题，MySQL将数据库的默认隔离级别设置为Repeatable Read。在Repeatable Read隔离级别下，针对更新数据时会不仅对更新的行加行级锁，还会增加GAP锁和next-key锁。在上述例子中，当事务 2 执行时，由于事务 1 添加了GAP锁和next-key锁，这将导致事务 2 执行被阻塞，需要等待事务 1 提交或回滚后才能继续执行。
除了设置默认的隔离级别外，MySQL还禁止在使用statement格式的binlog的情况下，将事务隔离级别设置为READ COMMITTED。
一旦用户主动修改隔离级别，尝试更新时，会报错：
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'
因此，我们现在明白了为什么MySQL选择Repeatable Read作为默认的数据库隔离级别了，实际上是为了与历史上那种statement格式的binlog保持兼容性。
