關于MySQL的事務隔離級別，相信很多讀者都不陌生，網商有很多種相關的文章，很多人對于各種隔離級別，以及不同的級別可以解決的一些讀現象都是如數家珍的。

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

RU隔離級別下，可能發生臟讀、幻讀、不可重復讀等問題。RC隔離級別下，解決了臟讀的問題，存在幻讀、不可重復讀的問題。RR隔離級別下，解決了臟讀、不可重復讀的問題，存在幻讀的問題。Serializable隔離級別下，解決了臟讀、幻讀、不可重復讀的問題。

這四種隔離級別是ANSI/ISO SQL定義的標準定義的，我們比較常用的MySQL對這四種隔離級別是都支持的。但是Oracle數據庫只支持Serializable和Read Committed。

但是，可能很多人都不知道，Oracle默認的隔離級別是 RC，而MySQL默認的隔離級別是 RR。

那么，你知道為什么Oracle選擇RC作為默認級別，而MySQL要選擇RR作為默認的隔離級別嗎？

這是我之前面試的時候，問過候選人的一個問題。

很多人認為這個問題沒有意義，這不是在逼著我們背八股文么？

但是其實并不是，如果你能耐心的看完這篇文章，你就會發現我的良苦用心。

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

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

Read-Only只讀隔離級別類似于可序列化隔離級別，但是只讀事務不允許在事務中修改數據，除非用戶是SYS。

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

相比于Oracle，MySQL的默認隔離級別的可選范圍就比較大了。

首先，我們先從四種隔離級別中排除Serializable和Read Uncommitted這兩種，主要是因為這兩個級別一個隔離級別太高，一個太低。太高的就會影響并發度，太低的就有臟讀現象。

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

這件事要從long long ago 說起。

在MySQL設計之處，他的定位就是提供一個穩定的關系型數據庫。而為了要解決MySQL單點故障帶來的問題，MySQL采用主從復制的機制。

所謂主從復制，其實就是通過搭建MySQL集群，整體對外提供服務，集群中的機器分為主服務器（Master）和從服務器（Slave），主服務器提供寫服務，從服務器提供讀服務。

為了保證主從服務器之間的數據的一致性，就需要進行數據同步，大致的同步過程如下，這里就不詳細介紹了

MySQL在主從復制的過程中，數據的同步是通過bin log進行的，簡單理解就是主服務器把數據變更記錄到bin log中，然后再把bin log同步傳輸給從服務器，從服務器接收到bin log之后，再把其中的數據恢復到自己的數據庫存儲中。

那么，binlog里面記錄的是什么內容呢？格式是怎樣的呢？

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

statement和row最大的區別，當binlog的格式為statemen時，binlog 里面記錄的就是 SQL 語句的原文（這句話很重要！！！后面會用的到）。

關于這幾種格式的區別，就不在這里詳細展開了，之所以要支持row格式，主要是因為statement格式中存在很多問題，最明顯的就是可能會導致主從數據庫的數據不一致。詳細介紹可以參考丁奇在極客時間上面的分享《MySQL實戰45講》。

那么，講這個主從同步和bin log我們要講的隔離級別有啥關系呢？

有關系，而且關系很大。

因為MySQL早期只有statement這種bin log格式，這時候，如果使用提交讀(Read Committed)、未提交讀(Read Uncommitted)這兩種隔離級別會出現問題。

比如，在MySQL官網上，有人就給官方曾經提過一個相關的Bug

這個bug的復現過程如下：

有一個數據庫表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);

接著開始執行兩個事務的寫操作：

以上兩個事務執行之后，數據庫里面的記錄會變成（11，2）和（20，2），這個發上在主庫的數據變更大家都能理解。

因為事務的隔離級別是read committed，所以，事務1在更新時，只會對b=2這行加上行級鎖，不會影響到事務2對b=1這行的寫操作。

以上兩個事務執行之后，會在bin log中記錄兩條記錄，因為事務2先提交，所以UPDATE t1 SET b=2 where b=1;會被優先記錄，然后再記錄UPDATE t1 SET a=11 where b=2;（再次提醒：statement格式的bin log記錄的是SQL語句的原文）

這樣bin log同步到備庫之后，SQL語句回放時，會先執行UPDATE t1 SET b=2 where b=1;，再執行UPDATE t1 SET a=11 where b=2;。

這時候，數據庫中的數據就會變成（11，2）和（11，2）。這就導致主庫和備庫的數據不一致了！！！

為了避免這樣的問題發生。MySQL就把數據庫的默認隔離級別設置成了Repetable Read，那么，Repetable Read的隔離級別下是如何解決這樣問題的那？

那是因為Repetable Read這種隔離級別，會在更新數據的時候不僅對更新的行加行級鎖，還會增加GAP lock。上面的例子，在事務2執行的時候，因為事務1增加了GAP lock，就會導致事務執行被卡住，需要等事務1提交或者回滾后才能繼續執行。（關于GAP lock，我后面會有文章單獨介紹）。

除了設置默認的隔離級別外，MySQL還禁止在使用statement格式的bin log的情況下，使用READ COMMITTED作為事務隔離級別。

一旦用戶主動修改隔離級別，嘗試更新時，會報錯：

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

所以，現在我們知道了，為什么MySQL選擇RR作為默認的數據庫隔離級別了吧，其實就是為了兼容歷史上的那種statement格式的bin log。

那么，本文講到這里，算是關于MySQL隔離級別這個知識點講了大概不到1/5吧，通過這篇文章， 你或許還會有以下問題：

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

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

3、RR和RC到底有什么區別？RC是如何解決不可重復讀問題的？

4、既然MySQL數據庫默認選擇了RR，那么，為啥像阿里這種大的互聯網公司會把默認的隔離級別改成RC？

關于以上幾個問題，你知道答案嗎，或者你對哪個更感興趣呢？歡迎留言！我會挑大家較為感興趣的專題在后面的文章中繼續深入展開介紹。

現在你還覺得這個問題沒有意義嗎？

我其實是想通過這樣一個看似無意義的問題，延展出更多的知識，這樣可以更加全方位的了解候選人。

到此這篇關于為什么MySQL選擇Repeatable Read作為默認隔離級別的文章就介紹到這了,更多相關MySQL Repeatable Read默認隔離級別內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！