關(guān)于MySQL的事務(wù)隔離級(jí)別，相信很多讀者都不陌生，網(wǎng)商有很多種相關(guān)的文章，很多人對(duì)于各種隔離級(jí)別，以及不同的級(jí)別可以解決的一些讀現(xiàn)象都是如數(shù)家珍的。

我們知道，ANSI/ISO SQL定義的標(biāo)準(zhǔn)隔離級(jí)別有四種，從高到底依次為：可序列化(Serializable)、可重復(fù)讀(Repeatable Reads)、提交讀(Read Committed)、未提交讀(Read Uncommitted)。

RU隔離級(jí)別下，可能發(fā)生臟讀、幻讀、不可重復(fù)讀等問(wèn)題。RC隔離級(jí)別下，解決了臟讀的問(wèn)題，存在幻讀、不可重復(fù)讀的問(wèn)題。RR隔離級(jí)別下，解決了臟讀、不可重復(fù)讀的問(wèn)題，存在幻讀的問(wèn)題。Serializable隔離級(jí)別下，解決了臟讀、幻讀、不可重復(fù)讀的問(wèn)題。

這四種隔離級(jí)別是ANSI/ISO SQL定義的標(biāo)準(zhǔn)定義的，我們比較常用的MySQL對(duì)這四種隔離級(jí)別是都支持的。但是Oracle數(shù)據(jù)庫(kù)只支持Serializable和Read Committed。

但是，可能很多人都不知道，Oracle默認(rèn)的隔離級(jí)別是 RC，而MySQL默認(rèn)的隔離級(jí)別是 RR。

那么，你知道為什么Oracle選擇RC作為默認(rèn)級(jí)別，而MySQL要選擇RR作為默認(rèn)的隔離級(jí)別嗎？

這是我之前面試的時(shí)候，問(wèn)過(guò)候選人的一個(gè)問(wèn)題。

很多人認(rèn)為這個(gè)問(wèn)題沒(méi)有意義，這不是在逼著我們背八股文么？

但是其實(shí)并不是，如果你能耐心的看完這篇文章，你就會(huì)發(fā)現(xiàn)我的良苦用心。

Oracle 的隔離級(jí)別

前面我們說(shuō)過(guò)，Oracle只只支持ANSI/ISO SQL定義的Serializable和Read Committed，其實(shí)，根據(jù)Oracle官方文檔給出的介紹，Oracle支持三種隔離級(jí)別：

即Oracle支持Read Committed、Serializable和Read-Only。

Read-Only只讀隔離級(jí)別類(lèi)似于可序列化隔離級(jí)別，但是只讀事務(wù)不允許在事務(wù)中修改數(shù)據(jù)，除非用戶(hù)是SYS。

在Oracle這三種隔離級(jí)別中，Serializable和Read-Only顯然都是不適合作為默認(rèn)隔離級(jí)別的，那么就只剩Read Committed這個(gè)唯一的選擇了。

MySQL 的隔離級(jí)別

相比于Oracle，MySQL的默認(rèn)隔離級(jí)別的可選范圍就比較大了。

首先，我們先從四種隔離級(jí)別中排除Serializable和Read Uncommitted這兩種，主要是因?yàn)檫@兩個(gè)級(jí)別一個(gè)隔離級(jí)別太高，一個(gè)太低。太高的就會(huì)影響并發(fā)度，太低的就有臟讀現(xiàn)象。

那么，剩下的RR和RC兩種，怎么選？

這件事要從long long ago 說(shuō)起。

在MySQL設(shè)計(jì)之處，他的定位就是提供一個(gè)穩(wěn)定的關(guān)系型數(shù)據(jù)庫(kù)。而為了要解決MySQL單點(diǎn)故障帶來(lái)的問(wèn)題，MySQL采用主從復(fù)制的機(jī)制。

所謂主從復(fù)制，其實(shí)就是通過(guò)搭建MySQL集群，整體對(duì)外提供服務(wù)，集群中的機(jī)器分為主服務(wù)器（Master）和從服務(wù)器（Slave），主服務(wù)器提供寫(xiě)服務(wù)，從服務(wù)器提供讀服務(wù)。

為了保證主從服務(wù)器之間的數(shù)據(jù)的一致性，就需要進(jìn)行數(shù)據(jù)同步，大致的同步過(guò)程如下，這里就不詳細(xì)介紹了

MySQL在主從復(fù)制的過(guò)程中，數(shù)據(jù)的同步是通過(guò)bin log進(jìn)行的，簡(jiǎn)單理解就是主服務(wù)器把數(shù)據(jù)變更記錄到bin log中，然后再把bin log同步傳輸給從服務(wù)器，從服務(wù)器接收到bin log之后，再把其中的數(shù)據(jù)恢復(fù)到自己的數(shù)據(jù)庫(kù)存儲(chǔ)中。

那么，binlog里面記錄的是什么內(nèi)容呢？格式是怎樣的呢？

MySQL的bin log主要支持三種格式，分別是statement、row以及mixed。MySQL是在5.1.5版本開(kāi)始支持row的、在5.1.8版本中開(kāi)始支持mixed。

statement和row最大的區(qū)別，當(dāng)binlog的格式為statemen時(shí)，binlog 里面記錄的就是 SQL 語(yǔ)句的原文（這句話(huà)很重要！??！后面會(huì)用的到）。

關(guān)于這幾種格式的區(qū)別，就不在這里詳細(xì)展開(kāi)了，之所以要支持row格式，主要是因?yàn)閟tatement格式中存在很多問(wèn)題，最明顯的就是可能會(huì)導(dǎo)致主從數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致。詳細(xì)介紹可以參考丁奇在極客時(shí)間上面的分享《MySQL實(shí)戰(zhàn)45講》。

那么，講這個(gè)主從同步和bin log我們要講的隔離級(jí)別有啥關(guān)系呢？

有關(guān)系，而且關(guān)系很大。

因?yàn)镸ySQL早期只有statement這種bin log格式，這時(shí)候，如果使用提交讀(Read Committed)、未提交讀(Read Uncommitted)這兩種隔離級(jí)別會(huì)出現(xiàn)問(wèn)題。

比如，在MySQL官網(wǎng)上，有人就給官方曾經(jīng)提過(guò)一個(gè)相關(guān)的Bug

這個(gè)bug的復(fù)現(xiàn)過(guò)程如下：

有一個(gè)數(shù)據(jù)庫(kù)表t1，表中有如下兩條記錄：

   CREATE TABLE t1 (

      a int(11) DEFAULT NULL,

      b int(11) DEFAULT NULL,

      KEY a (a)

    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

    insert into t1 values(10,2),(20,1);

接著開(kāi)始執(zhí)行兩個(gè)事務(wù)的寫(xiě)操作：

以上兩個(gè)事務(wù)執(zhí)行之后，數(shù)據(jù)庫(kù)里面的記錄會(huì)變成（11，2）和（20，2），這個(gè)發(fā)上在主庫(kù)的數(shù)據(jù)變更大家都能理解。

因?yàn)槭聞?wù)的隔離級(jí)別是read committed，所以，事務(wù)1在更新時(shí)，只會(huì)對(duì)b=2這行加上行級(jí)鎖，不會(huì)影響到事務(wù)2對(duì)b=1這行的寫(xiě)操作。

以上兩個(gè)事務(wù)執(zhí)行之后，會(huì)在bin log中記錄兩條記錄，因?yàn)槭聞?wù)2先提交，所以UPDATE t1 SET b=2 where b=1;會(huì)被優(yōu)先記錄，然后再記錄UPDATE t1 SET a=11 where b=2;（再次提醒：statement格式的bin log記錄的是SQL語(yǔ)句的原文）

這樣bin log同步到備庫(kù)之后，SQL語(yǔ)句回放時(shí)，會(huì)先執(zhí)行UPDATE t1 SET b=2 where b=1;，再執(zhí)行UPDATE t1 SET a=11 where b=2;。

這時(shí)候，數(shù)據(jù)庫(kù)中的數(shù)據(jù)就會(huì)變成（11，2）和（11，2）。這就導(dǎo)致主庫(kù)和備庫(kù)的數(shù)據(jù)不一致了?。。?/p>

為了避免這樣的問(wèn)題發(fā)生。MySQL就把數(shù)據(jù)庫(kù)的默認(rèn)隔離級(jí)別設(shè)置成了Repetable Read，那么，Repetable Read的隔離級(jí)別下是如何解決這樣問(wèn)題的那？

那是因?yàn)镽epetable Read這種隔離級(jí)別，會(huì)在更新數(shù)據(jù)的時(shí)候不僅對(duì)更新的行加行級(jí)鎖，還會(huì)增加GAP lock。上面的例子，在事務(wù)2執(zhí)行的時(shí)候，因?yàn)槭聞?wù)1增加了GAP lock，就會(huì)導(dǎo)致事務(wù)執(zhí)行被卡住，需要等事務(wù)1提交或者回滾后才能繼續(xù)執(zhí)行。（關(guān)于GAP lock，我后面會(huì)有文章單獨(dú)介紹）。

除了設(shè)置默認(rèn)的隔離級(jí)別外，MySQL還禁止在使用statement格式的bin log的情況下，使用READ COMMITTED作為事務(wù)隔離級(jí)別。

一旦用戶(hù)主動(dòng)修改隔離級(jí)別，嘗試更新時(shí)，會(huì)報(bào)錯(cuò)：

 ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'

總結(jié)

所以，現(xiàn)在我們知道了，為什么MySQL選擇RR作為默認(rèn)的數(shù)據(jù)庫(kù)隔離級(jí)別了吧，其實(shí)就是為了兼容歷史上的那種statement格式的bin log。

那么，本文講到這里，算是關(guān)于MySQL隔離級(jí)別這個(gè)知識(shí)點(diǎn)講了大概不到1/5吧，通過(guò)這篇文章， 你或許還會(huì)有以下問(wèn)題：

1、row格式和statement有什么區(qū)別？使用row的情況下，可以使用RR嗎？

2、文中提到的RC的GAP lock到底是什么？

3、RR和RC到底有什么區(qū)別？RC是如何解決不可重復(fù)讀問(wèn)題的？

4、既然MySQL數(shù)據(jù)庫(kù)默認(rèn)選擇了RR，那么，為啥像阿里這種大的互聯(lián)網(wǎng)公司會(huì)把默認(rèn)的隔離級(jí)別改成RC？

關(guān)于以上幾個(gè)問(wèn)題，你知道答案嗎，或者你對(duì)哪個(gè)更感興趣呢？歡迎留言！我會(huì)挑大家較為感興趣的專(zhuān)題在后面的文章中繼續(xù)深入展開(kāi)介紹。

現(xiàn)在你還覺(jué)得這個(gè)問(wèn)題沒(méi)有意義嗎？

我其實(shí)是想通過(guò)這樣一個(gè)看似無(wú)意義的問(wèn)題，延展出更多的知識(shí)，這樣可以更加全方位的了解候選人。

到此這篇關(guān)于為什么MySQL選擇Repeatable Read作為默認(rèn)隔離級(jí)別的文章就介紹到這了,更多相關(guān)MySQL Repeatable Read默認(rèn)隔離級(jí)別內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論