InnoDB 的默认隔离级别是什么？

分析&回答

大部分数据库系统（如Oracle）都将都将读提交（Read-Commited）作为默认隔离级别，而MySQL却选择可重复读（Repeatable-Read）作为其默认隔离级别。

如果没有隔离级别基础知识的话先看看：说说Mysql的四种隔离级别

看个总结的表格

事务隔离级别	脏读	不可重复读	幻读
读未提交	是	是	是
不可重复读	否	是	是
可重复读	否	否	是
串行化	否	否	否

为何会采用可重复读作为其默认隔离级别？

先看看binlog日志三种记录模式和各有优缺点：MySQL默认的binlog记录模式为row。

在早期版本的MySQL中，binlog只有statement这一种记录模式，而此种模式导致的一个致命问题就是，在读提交（RC）隔离级别下会导致主从数据不一致。在binlog中，记录日志的规则为：事务commit之后，记录日志。

我们看下在RC隔离机制下的一个案例：假设此时binlog记录模式为statement。那么记录binlog的顺序为：t4时刻，记录t1表的delete语句；t6时刻，记录对t表的update语句。之后主从同步，master将自身的binlog同步给slave，slave执行同步时就会遇到的一个问题：slave会先执行删除t1表的内容，再执行更新t表的记录，此时会导致主从不一致。

接下来，我们在看下在RR隔离机制下的相同案例：在RR隔离机制下，事务B的操作被阻塞，所以不会使得binlog在statement模式下记录顺序出现颠倒而导致主从数据不一致问题。

RR隔离机制下的相同案例：在RR隔离机制下，事务B的操作被阻塞，所以不会使得binlog在statement模式下记录顺序出现颠倒而导致主从数据不一致问题。

所以，由于早期MySQL版本中binlog只有statement模式，而在读提交（RC）隔离级别下记录的binlog使用statement模式会导致主从数据不一致的问题，所以，MySQL选择使用可重复读（RR）作为默认隔离级别以保证主从复制数据一致性。

反思&扩展

MySQL之所以选择可重读事务隔离机制是因为早期binlog只支持statement格式，而此种格式在读提交隔离机制下回导致主从不一致。MySQL的可重读隔离机制解决幻读的问题关键是靠MVCC的实现，事务ID和行版本ID保证了读取的一致性和隔离性。在MySQL中，通过多版本并发控制（MVCC）去避免幻读的问题，但是只是在select的时候可以避免幻读，update之后再select还是可能会出现幻读现象。