[[439824]]

 我之前寫過一篇文章《為什么MySQL選擇REPEATABLE READ作為默認隔離級別？》介紹過MySQL 的默認隔離級別是 Repeatable Reads以及背后的原因。

主要是因為MySQL在主從復制的過程是通過bin log 進行數據同步的，而MySQL早期只有statement這種bin log格式，這種格式下，bin log記錄的是SQL語句的原文。

當出現事務亂序的時候，就會導致備庫在 SQL 回放之后，結果和主庫內容不一致。

為了解決這個問題，MySQL默認采用了Repetable Read這種隔離級別，因為在 RR 中，會在更新數據的時候增加記錄鎖的同時增加間隙鎖?？梢员苊膺@種情況的發生。

關于MySQL的加鎖方式及加鎖原則，可以參考我寫的另外一篇《求你了，別再說數據庫鎖的只是索引了！》，這里就不再贅述了。

在我知道MySQL 默認隔離級別是RR后，很長一段時間都以為應該不會有人去修改這個默認配置。

但是直到有一天，我們線上發生了一次死鎖的問題，我在排查的過程中，才發現我們的數據庫用的隔離級別沒有使用默認的 RR，而是修改成了Read Committed 。（關于那次死鎖排查過程，可以參考：一次數據庫的死鎖問題排查過程）

大家可以通過這個命令查看數據庫當前的隔離級別： 

select @@tx_isolation; 

那么，這里不禁就有疑問了，為啥阿里要把這個數據庫隔離級別修改成 RC 呢，背后有什么思考嗎？

RR 和 RC 的區別

想要搞清楚這個問題，我們需要先弄清楚 RR 和 RC 的區別，分析下各自的優缺點。

一致性讀

一致性讀，又稱為快照讀?？煺占串斍靶袛祿暗臍v史版本?？煺兆x就是使用快照信息顯示基于某個時間點的查詢結果，而不考慮與此同時運行的其他事務所執行的更改。

在MySQL 中，只有READ COMMITTED 和 REPEATABLE READ這兩種事務隔離級別才會使用一致性讀。

在 RC 中，每次讀取都會重新生成一個快照，總是讀取行的最新版本。

在 RR 中，快照會在事務中第一次SELECT語句執行時生成，只有在本事務中對數據進行更改才會更新快照。

在數據庫的 RC 這種隔離級別中，還支持"半一致讀" ，一條update語句，如果 where 條件匹配到的記錄已經加鎖，那么InnoDB會返回記錄最近提交的版本，由MySQL上層判斷此是否需要真的加鎖。

鎖機制

數據庫的鎖，在不同的事務隔離級別下，是采用了不同的機制的。在 MySQL 中，有三種類型的鎖，分別是Record Lock、Gap Lock和 Next-Key Lock。

Record Lock表示記錄鎖，鎖的是索引記錄。

Gap Lock是間隙鎖，鎖的是索引記錄之間的間隙。

Next-Key Lock是Record Lock和Gap Lock的組合，同時鎖索引記錄和間隙。他的范圍是左開右閉的。

在 RC 中，只會對索引增加Record Lock，不會添加Gap Lock和Next-Key Lock。

在 RR 中，為了解決幻讀的問題，在支持Record Lock的同時，還支持Gap Lock和Next-Key Lock；

主從同步

在數據主從同步時，不同格式的 binlog 也對事務隔離級別有要求。

MySQL的binlog主要支持三種格式，分別是statement、row以及mixed，但是，RC 隔離級別只支持row格式的binlog。如果指定了mixed作為 binlog 格式，那么如果使用RC，服務器會自動使用基于row 格式的日志記錄。

而 RR 的隔離級別同時支持statement、row以及mixed三種。

為什么互聯網公司選擇使用 RC

提升并發

互聯網公司和傳統企業最大的區別是什么？

高并發！

沒錯，互聯網業務的并發度比傳統企業要高處很多。2020年雙十一當天，訂單創建峰值達到 58.3 萬筆/秒。

很多人問，要怎么做才能扛得住這么大的并發量。其實，這背后的優化多到幾個小時都講不完，因為要做的、可以做的事情實在是太多了。

而有一個和我們今天這篇文章有關的優化，那就是通過修改數據庫的隔離級別來提升并發度。

為什么 RC 比 RR 的并發度要好呢？

首先，RC 在加鎖的過程中，是不需要添加Gap Lock和 Next-Key Lock 的，只對要修改的記錄添加行級鎖就行了。

這就使得并發度要比 RR 高很多。

另外，因為 RC 還支持"半一致讀"，可以大大的減少了更新語句時行鎖的沖突；對于不滿足更新條件的記錄，可以提前釋放鎖，提升并發度。

減少死鎖

因為RR這種事務隔離級別會增加Gap Lock和 Next-Key Lock，這就使得鎖的粒度變大，那么就會使得死鎖的概率增大。

 死鎖：一個事務鎖住了表A，然后又訪問表B；另一個事務鎖住了表B，然后企圖訪問表A；這時就會互相等待對方釋放鎖，就導致了死鎖。

總結

本文介紹了一些 MySQL數據庫的 RR 和 RC 兩種事務隔離級別。他們主要在加鎖機制、主從同步以及一致性讀方面存在一些差異。

而很多大廠，為了提升并發度和降低死鎖發生的概率，會把數據庫的隔離級別從默認的 RR 調整成 RC。

當然，這樣做也不是完全沒有問題，首先使用 RC 之后，就需要自己解決幻讀的問題，這個其實還好，很多時候幻讀問題其實是可以忽略的，或者可以用其他手段解決。

還有就是使用 RC 的時候，不能使用statement格式的 binlog，這種影響其實可以忽略不計了，因為MySQL是在5.1.5版本開始支持row的、在5.1.8版本中開始支持mixed，后面這兩種可以代替 statement格式。