MySQL数据库的默认隔离级别为什么是可重复读

共计 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)，保证主从复制不出问题。