對(duì)于數(shù)據(jù)庫的默認(rèn)隔離級(jí)別，Oracle默認(rèn)的隔離級(jí)別是 RC，而MySQL默認(rèn)的隔離級(jí)別是 RR。

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

Oracle的隔離級(jí)別

Oracle支持ANSI/ISO SQL定義的Serializable和Read Committed兩種隔離級(jí)別，根據(jù)Oracle官方文檔的介紹，Oracle的隔離級(jí)別包括Read Committed、Serializable和Read-Only。

圖片

Read-Only的隔離級(jí)別類似于Serializable，然而僅允許只讀事務(wù)進(jìn)行數(shù)據(jù)檢索，不允許在事務(wù)中修改數(shù)據(jù)，除非使用者是SYS用戶。

在Oracle的這三種隔離級(jí)別中，顯而易見，Serializable和Read-Only都不適合作為默認(rèn)隔離級(jí)別，因此唯一的選擇就是Read Committed了。

MySQL的隔離級(jí)別

與Oracle相比，MySQL提供的默認(rèn)隔離級(jí)別范圍更加廣泛。

首先，我們排除了Serializable和Read Uncommitted這兩種級(jí)別，原因是一個(gè)隔離級(jí)別過高會(huì)影響并發(fā)度，另一個(gè)過低則存在臟讀問題。

剩下的RR和RC兩種，如何選擇呢？

MySQL在設(shè)計(jì)之初就旨在提供一個(gè)穩(wěn)定的關(guān)系型數(shù)據(jù)庫。為解決MySQL單點(diǎn)故障問題，MySQL采取了主從復(fù)制機(jī)制。

所謂的主從復(fù)制，即通過建立MySQL集群，以整體向外提供服務(wù)。集群內(nèi)的機(jī)器分為主服務(wù)器（Master）和從服務(wù)器（Slave），主服務(wù)器負(fù)責(zé)提供寫服務(wù)，而從服務(wù)器則提供讀服務(wù)。

在MySQL主從復(fù)制過程中，數(shù)據(jù)的同步通過binlog進(jìn)行。簡單來說，主服務(wù)器將數(shù)據(jù)變更記錄到binlog中，然后將binlog同步傳輸給從服務(wù)器。從服務(wù)器接收到binlog后，將其中的數(shù)據(jù)恢復(fù)到自己的數(shù)據(jù)庫存儲(chǔ)中。

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

MySQL的binlog主要支持三種格式，即statement、row和mixed。MySQL從5.1.5版本開始支持row格式，在5.1.8版本中開始支持mixed格式。

statement和row之間最重要的區(qū)別在于，當(dāng)binlog的格式為statement時(shí)，binlog記錄的是SQL語句的原文。

由于MySQL早期僅支持statement這一種binlog格式，因此在使用提交讀（Read Committed）和未提交讀（Read Uncommitted）這兩種隔離級(jí)別時(shí)都可能會(huì)出現(xiàn)問題。

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

CREATE TABLE `t1` (
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  KEY `b` (`b`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

insert into t1 values(10,1);

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

以上兩個(gè)事務(wù)執(zhí)行之后，數(shù)據(jù)庫里面的記錄會(huì)只有一條記錄（10,99），這個(gè)發(fā)生在主庫的數(shù)據(jù)變更大家都能理解。

★

即使 Session 1 的刪除操作在 Session 2 的插入操作之后提交，由于 READ COMMITTED 的隔離級(jí)別，Session 2 的插入操作不會(huì)看到 Session 1 的刪除操作，所以最后數(shù)據(jù)庫中仍然會(huì)留下 Session 2 插入的記錄 (10,99)。

這種行為是 READ COMMITTED 隔禽級(jí)別的一種特性，它會(huì)在事務(wù)開始時(shí)創(chuàng)建一個(gè)快照。確保事務(wù)之間的隔離性，避免了數(shù)據(jù)不一致性的問題。

以上兩個(gè)事務(wù)執(zhí)行之后，會(huì)在bin log中記錄兩條記錄，因?yàn)槭聞?wù)2先提交，所以insert into t1 values(10,99);會(huì)被優(yōu)先記錄，然后再記錄delete from t1 where b < 100;（再次提醒：statement格式的bin log記錄的是SQL語句的原文）

這樣bin log同步到備庫之后，SQL語句回放時(shí)，會(huì)先執(zhí)行insert into t1 values(10,99);，再執(zhí)行delete from t1 where b < 100;。

這時(shí)候，數(shù)據(jù)庫中的數(shù)據(jù)就會(huì)變成 EMPTY SET，即沒有任何數(shù)據(jù)。這就導(dǎo)致主庫和備庫的數(shù)據(jù)不一致了！！！

為了解決這種問題，MySQL將數(shù)據(jù)庫的默認(rèn)隔離級(jí)別設(shè)置為Repeatable Read。在Repeatable Read隔離級(jí)別下，針對(duì)更新數(shù)據(jù)時(shí)會(huì)不僅對(duì)更新的行加行級(jí)鎖，還會(huì)增加GAP鎖和next-key鎖。在上述例子中，當(dāng)事務(wù) 2 執(zhí)行時(shí)，由于事務(wù) 1 添加了GAP鎖和next-key鎖，這將導(dǎo)致事務(wù) 2 執(zhí)行被阻塞，需要等待事務(wù) 1 提交或回滾后才能繼續(xù)執(zhí)行。

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

一旦用戶主動(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'

因此，我們現(xiàn)在明白了為什么MySQL選擇Repeatable Read作為默認(rèn)的數(shù)據(jù)庫隔離級(jí)別了，實(shí)際上是為了與歷史上那種statement格式的binlog保持兼容性。