为什么mysql选可重复读作为默认的隔离级别

Mysql默认的事务隔离级别是可重复读(Repeatable Read)，那互联网项目中Mysql也是用默认隔离级别，不做修改么？
OK，不是的，我们在项目中一般用读已提交(Read Commited)这个隔离级别！

1.为什么mysql选可重复读作为默认的隔离级别

在RR级别下，binlog为任何格式均不会造成主从数据不一致的情况出现，但是当低版本MySQL使用RC+STATEMENT组合时（MySQL5.1.5前只有statement格式）将会导致主从数据不一致。当前这个历史遗漏问题以及解决，大家可以将其设置为RC+ROW组合的方式

主从复制，基于binlog复制的！简单理解为binlog是一个记录数据库更改的文件吧～
binlog有三种格式：

• statement:记录的是修改SQL语句
• row：记录的是每行实际数据的变更
• mixed：statement和row模式的混合

那Mysql在5.0这个版本以前，binlog只支持STATEMENT这种格式！而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别！

2.项目中为什么不用读未提交(Read UnCommitted)和串行化(Serializable)两个隔离级别？

1. 采用读未提交(Read UnCommitted),一个事务读到另一个事务未提交读数据，从逻辑上都说不过去！
2. 采用串行化(Serializable)，每次读操作都会加锁，快照读失效，一般是使用mysql自带分布式事务功能时才使用该隔离级别！(笔者从未用过mysql自带的这个功能，因为这是XA事务，是强一致性事务，性能不佳！互联网的分布式方案，多采用最终一致性的事务解决方案！)

3.在RC级别下，主从复制用什么binlog格式？

用的binlog为row格式，是基于行的复制！

4.为什么互联网项目用读已提交(Read Commited)这个隔离级别？

在RC级别下，不可重复读问题需要解决么？
不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle的默认隔离级别就是RC，你们改过Oracle的默认隔离级别么？
缘由一：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！
此时执行语句
select * from test where id < 3 for update;
在RR隔离级别下，存在间隙锁，可以锁住(2,5)这个间隙，防止其他事务插入数据！
而在RC隔离级别下，不存在间隙锁，其他事务是可以插入数据！
ps:在RC隔离级别下并不是不会出现死锁，只是出现几率比RR低而已！
缘由二：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行