参考文献: 互联网项目中mysql应该选什么事务隔离级别
历史bug
mysql的默认隔离级别是可重复读, 是为了兼容历史bug, 目前该bug已经修复:
Mysql在5.0这个版本以前，binlog只支持STATEMENT这种格式！而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别！
将binglog的格式修改为row格式，此时是基于行的复制，自然就不会出现sql执行顺序不一样的问题！奈何这个格式在mysql5.1版本开始才引入。因此由于历史原因，mysql将默认的隔离级别设为可重复读(Repeatable Read)，保证主从复制不出问题！
选择读已提交的原因
为了便于描述，下面将:
可重复读(Repeatable Read)，简称为RR；
读已提交(Read Commited)，简称为RC；
缘由一：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！
缘由二：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行!
缘由三：在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！
总之就想说明, RC的并发性高于RR.
2个疑问
- 在RC级别下，不可重复读问题需要解决么？
不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle的默认隔离级别就是RC，你们改过Oracle的默认隔离级别么？
据我在金融机构的工作经历, 使用RC才是正确的行为, 这样可以察觉到其他并发事务的提交, 这样才能保证在更新金额时拿到其他事务修改后的值.
乐观锁是另外一回事, 一般用在2个用户在2个浏览器上修改同一个数据的时候, 有一个先查询, 再修改的过程. 且查询和修改各自都是短事务.
- 在RC级别下，主从复制用什么binlog格式？
OK,在该隔离级别下，用的binlog为row格式，是基于行的复制！Innodb的创始人也是建议binlog使用该格式！
总结
本文啰里八嗦了一篇文章只是为了说明一件事，互联网项目请用：读已提交(Read Commited)这个隔离级别！
