為什麼mysql選可重複讀作為預設的隔離級別

卜思凡發表於2020-09-28

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隔離級別下,只鎖行

相關文章