[[439824]]

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

主要是因?yàn)镸ySQL在主從復(fù)制的過程是通過bin log 進(jìn)行數(shù)據(jù)同步的，而MySQL早期只有statement這種bin log格式，這種格式下，bin log記錄的是SQL語句的原文。

當(dāng)出現(xiàn)事務(wù)亂序的時(shí)候，就會(huì)導(dǎo)致備庫在 SQL 回放之后，結(jié)果和主庫內(nèi)容不一致。

為了解決這個(gè)問題，MySQL默認(rèn)采用了Repetable Read這種隔離級(jí)別，因?yàn)樵?RR 中，會(huì)在更新數(shù)據(jù)的時(shí)候增加記錄鎖的同時(shí)增加間隙鎖。可以避免這種情況的發(fā)生。

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

在我知道MySQL 默認(rèn)隔離級(jí)別是RR后，很長一段時(shí)間都以為應(yīng)該不會(huì)有人去修改這個(gè)默認(rèn)配置。

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

大家可以通過這個(gè)命令查看數(shù)據(jù)庫當(dāng)前的隔離級(jí)別： 

select @@tx_isolation; 

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

RR 和 RC 的區(qū)別

想要搞清楚這個(gè)問題，我們需要先弄清楚 RR 和 RC 的區(qū)別，分析下各自的優(yōu)缺點(diǎn)。

一致性讀

一致性讀，又稱為快照讀?？煺占串?dāng)前行數(shù)據(jù)之前的歷史版本?？煺兆x就是使用快照信息顯示基于某個(gè)時(shí)間點(diǎn)的查詢結(jié)果，而不考慮與此同時(shí)運(yùn)行的其他事務(wù)所執(zhí)行的更改。

在MySQL 中，只有READ COMMITTED 和 REPEATABLE READ這兩種事務(wù)隔離級(jí)別才會(huì)使用一致性讀。

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

在 RR 中，快照會(huì)在事務(wù)中第一次SELECT語句執(zhí)行時(shí)生成，只有在本事務(wù)中對(duì)數(shù)據(jù)進(jìn)行更改才會(huì)更新快照。

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

鎖機(jī)制

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

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

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

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

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

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

主從同步

在數(shù)據(jù)主從同步時(shí)，不同格式的 binlog 也對(duì)事務(wù)隔離級(jí)別有要求。

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

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

為什么互聯(lián)網(wǎng)公司選擇使用 RC

提升并發(fā)

互聯(lián)網(wǎng)公司和傳統(tǒng)企業(yè)最大的區(qū)別是什么？

高并發(fā)！

沒錯(cuò)，互聯(lián)網(wǎng)業(yè)務(wù)的并發(fā)度比傳統(tǒng)企業(yè)要高處很多。2020年雙十一當(dāng)天，訂單創(chuàng)建峰值達(dá)到 58.3 萬筆/秒。

很多人問，要怎么做才能扛得住這么大的并發(fā)量。其實(shí)，這背后的優(yōu)化多到幾個(gè)小時(shí)都講不完，因?yàn)橐龅?、可以做的事情?shí)在是太多了。

而有一個(gè)和我們今天這篇文章有關(guān)的優(yōu)化，那就是通過修改數(shù)據(jù)庫的隔離級(jí)別來提升并發(fā)度。

為什么 RC 比 RR 的并發(fā)度要好呢？

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

這就使得并發(fā)度要比 RR 高很多。

另外，因?yàn)?RC 還支持"半一致讀"，可以大大的減少了更新語句時(shí)行鎖的沖突；對(duì)于不滿足更新條件的記錄，可以提前釋放鎖，提升并發(fā)度。

減少死鎖

因?yàn)镽R這種事務(wù)隔離級(jí)別會(huì)增加Gap Lock和 Next-Key Lock，這就使得鎖的粒度變大，那么就會(huì)使得死鎖的概率增大。

 死鎖：一個(gè)事務(wù)鎖住了表A，然后又訪問表B；另一個(gè)事務(wù)鎖住了表B，然后企圖訪問表A；這時(shí)就會(huì)互相等待對(duì)方釋放鎖，就導(dǎo)致了死鎖。

總結(jié)

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

而很多大廠，為了提升并發(fā)度和降低死鎖發(fā)生的概率，會(huì)把數(shù)據(jù)庫的隔離級(jí)別從默認(rèn)的 RR 調(diào)整成 RC。

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

還有就是使用 RC 的時(shí)候，不能使用statement格式的 binlog，這種影響其實(shí)可以忽略不計(jì)了，因?yàn)镸ySQL是在5.1.5版本開始支持row的、在5.1.8版本中開始支持mixed，后面這兩種可以代替 statement格式。