分析&回答
大部分数据库系统（如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还是可能会出现幻读现象。
喵呜面试助手：一站式解决面试问题，你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] -> 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享！