av一区二区在线观看_亚洲男人的天堂网站_日韩亚洲视频_在线成人免费_欧美日韩精品免费观看视频_久草视

您的位置:首頁技術(shù)文章
文章詳情頁

為什么MySQL選擇Repeatable Read作為默認隔離級別

瀏覽:28日期:2023-10-01 08:29:37
目錄Oracle 的隔離級別MySQL 的隔離級別總結(jié)

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

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

為什么MySQL選擇Repeatable Read作為默認隔離級別

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

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

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

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

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

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

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

Oracle 的隔離級別

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

為什么MySQL選擇Repeatable Read作為默認隔離級別

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

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

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

MySQL 的隔離級別

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

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

那么,剩下的RR和RC兩種,怎么選?

這件事要從long long ago 說起。

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

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

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

為什么MySQL選擇Repeatable Read作為默認隔離級別

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

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

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

statement和row最大的區(qū)別,當binlog的格式為statemen時,binlog 里面記錄的就是 SQL 語句的原文(這句話很重要!!!后面會用的到)。

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

那么,講這個主從同步和bin log我們要講的隔離級別有啥關(guān)系呢?

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

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

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

為什么MySQL選擇Repeatable Read作為默認隔離級別

這個bug的復(fù)現(xiàn)過程如下:

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

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

為什么MySQL選擇Repeatable Read作為默認隔離級別

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

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

以上兩個事務(wù)執(zhí)行之后,會在bin log中記錄兩條記錄,因為事務(wù)2先提交,所以UPDATE t1 SET b=2 where b=1;會被優(yōu)先記錄,然后再記錄UPDATE t1 SET a=11 where b=2;(再次提醒:statement格式的bin log記錄的是SQL語句的原文)

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

這時候,數(shù)據(jù)庫中的數(shù)據(jù)就會變成(11,2)和(11,2)。這就導(dǎo)致主庫和備庫的數(shù)據(jù)不一致了!!!

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

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

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

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

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作為默認的數(shù)據(jù)庫隔離級別了吧,其實就是為了兼容歷史上的那種statement格式的bin log。

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

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

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

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

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

關(guān)于以上幾個問題,你知道答案嗎,或者你對哪個更感興趣呢?歡迎留言!我會挑大家較為感興趣的專題在后面的文章中繼續(xù)深入展開介紹。

現(xiàn)在你還覺得這個問題沒有意義嗎?

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

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

相關(guān)文章:
主站蜘蛛池模板: 国产不卡视频 | 国产91色 | 17c一起操| 特级特黄aaaa免费看 | 亚洲综合成人网 | 久久久久久久久久国产 | 在线观看av网站 | 免费观看一区二区 | 96精品 | 青草视频网站 | 欧美美女一区二区 | 亚洲精品日韩精品 | 亚洲美女网站 | 中文字幕高清 | 手机看片福利永久 | 日韩综合久久 | 欧美91 | 国产欧美综合一区二区三区 | 国产伊人网 | 欧美一级欧美三级在线观看 | 日韩欧美高清视频 | 一区二区三区影视 | 中文字幕伊人 | 亚洲黄色精品 | 天天干夜夜撸 | 黄色大毛片 | 日韩欧美一级 | 久草视| 国产传媒在线观看 | 国产精品久久久久久久久久久久久久久 | 久久久亚洲天堂 | 国产精品日韩欧美 | 黄色一级网站 | 黄色国产精品 | 97人人草 | 亚洲精品视频一区 | 91手机在线视频 | 欧美日韩精品一区二区 | 日韩欧美视频 | 欧美日韩在线观看视频 | 中文字幕欧美激情 |