為什麼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隔離級別下，只鎖行