共计 1029 个字符，预计需要花费 3 分钟才能阅读完成。
一般的 DBMS 系统，默认都会使用读提交（Read-Comitted，RC）作为默认隔离级别，如 Oracle、SQLServer 等，而 MySQL 却使用可重复读（Read-Repeatable，RR）。要知道，越高的隔离级别，能解决的数据一致性问题越多，理论上性能损耗更大，可并发性越低。隔离级别依次为 >：串行化 > RR > RC > 读未提交
在 SQL 标准中，前三种隔离级别分别解决了幻象读、不可重复读和脏读的问题。那么，为什么 MySQL 使用可重复读作为默认隔离级别呢？
这个是有历史原因的，要从主从复制开始讲起了！
1. 主从复制，是基于什么复制的？
是基于 binlog 复制的
2.binlog 有几种格式？
statement: 记录的是修改 SQL 语句
row：记录的是每行实际数据的变更
mixed：statement 和 row 模式的混合
那 Mysql 在 5.0 这个版本以前，binlog 只支持 STATEMENT 这种格式！而这种格式在读已提交 (Read Commited) 这个隔离级别下主从复制是有 bug 的，因此 Mysql 将可重复读 (Repeatable Read) 作为默认的隔离级别！
接下来，就要说说当 binlog 为 STATEMENT 格式，且隔离级别为读已提交 (Read Commited) 时，有什么 bug 呢？如下图所示，在主 (master) 上执行如下事务:
此时在主库中查询：
select * from t;
输出结果：
+---+---+
| c1 |c2
+---+---+
| 2 | 2
+---+---+
1 row in set
从库中查询：
select * from t;
输出结果：
Empty set
这里出现了主从不一致性的问题！原因其实很简单，就是在 master 上执行的顺序为先删后插！而此时 binlog 为 STATEMENT 格式，它记录的顺序为先插后删！从 (slave) 同步的是 binglog，因此从机执行的顺序和主机不一致！就会出现主从不一致！
如何解决？
解决方案有两种！
(1)隔离级别设为可重复读(Repeatable Read), 在该隔离级别下引入间隙锁。当 Session 1 执行 delete 语句时，会锁住间隙。那么，Ssession 2 执行插入语句就会阻塞住！
(2)将 binglog 的格式修改为 row 格式，此时是基于行的复制，自然就不会出现 sql 执行顺序不一样的问题！奈何这个格式在 mysql5.1 版本开始才引入。
因此由于历史原因，mysql 将默认的隔离级别设为可重复读(Repeatable Read)，保证主从复制不出问题。
