之前看過一篇文章介紹過MySQL 的默認(rèn)隔離級(jí)別是 Repeatable Reads以及背后的原因忧勿。
主要是因?yàn)?b>MySQL在主從復(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)?b>在 RR 中廉白，會(huì)在更新數(shù)據(jù)的時(shí)候增加記錄鎖的同時(shí)增加間隙鎖」院可以避免這種情況的發(fā)生猴蹂。
在我知道MySQL 默認(rèn)隔離級(jí)別是RR后，很長(zhǎng)一段時(shí)間都以為應(yīng)該不會(huì)有人去修改這個(gè)默認(rèn)配置楣嘁。
但是直到有一天磅轻，我們線上發(fā)生了一次死鎖的問題，我在排查的過程中逐虚，才發(fā)現(xiàn)我們的數(shù)據(jù)庫用的隔離級(jí)別沒有使用默認(rèn)的 RR聋溜，而是修改成了Read Committed 。
大家可以通過這個(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ù)之前的歷史版本叙赚。快照讀就是使用快照信息顯示基于某個(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格式。
所有的技術(shù)方案的選擇将塑，都是一種權(quán)衡的藝術(shù)脉顿！
