真正理解Mysql的四種隔離級別,看了都說好

點擊上方 "程序員小樂"關注, 星標或置頂一起成長

每天凌晨00點00分, 第一時間與你相約


每日英文

What other people think of you is none of your business. Trust the feeling more than the words.

別人怎麼看你,和你毫無關係。更多的相信自己的感覺,而非別人的言語。


每日掏心話

別為了那些不屬於你的觀眾,去演繹不擅長的人生。別人怎麼看你,和你毫無關係。你要怎麼活,也和別人毫無關係。


鏈接:jianshu.com/p/8d735db9c2c0


真正理解Mysql的四種隔離級別,看了都說好

程序員小樂(ID:study_tech)第 810 次推文 圖片來自百度


往日回顧:就為了10萬塊?前百度程序員,非法控制公司上百臺服務器“挖礦”被判3年


正文


什麼是事務

事務是應用程序中一系列嚴密的操作,所有操作必須成功完成,否則在每個操作中所作的所有更改都會被撤消。也就是事務具有原子性,一個事務中的一系列的操作要麼全部成功,要麼一個都不做。

事務的結束有兩種,當事務中的所以步驟全部成功執行時,事務提交。如果其中一個步驟失敗,將發生回滾操作,撤消撤消之前到事務開始時的所以操作。

事務的 ACID

事務具有四個特徵:原子性( Atomicity )、一致性( Consistency )、隔離性( Isolation )和持續性( Durability )。這四個特性簡稱為 ACID 特性。


  • 原子性。事務是數據庫的邏輯工作單位,事務中包含的各操作要麼都做,要麼都不做

  • 一致性。事 務執行的結果必須是使數據庫從一個一致性狀態變到另一個一致性狀態。因此當數據庫只包含成功事務提交的結果時,就說數據庫處於一致性狀態。如果數據庫系統 運行中發生故障,有些事務尚未完成就被迫中斷,這些未完成事務對數據庫所做的修改有一部分已寫入物理數據庫,這時數據庫就處於一種不正確的狀態,或者說是 不一致的狀態。

  • 隔離性。一個事務的執行不能其它事務干擾。即一個事務內部的操作及使用的數據對其它併發事務是隔離的,併發執行的各個事務之間不能互相干擾。

  • 持續性。也稱永久性,指一個事務一旦提交,它對數據庫中的數據的改變就應該是永久性的。接下來的其它操作或故障不應該對其執行結果有任何影響。


Mysql的四種隔離級別

SQL標準定義了4類隔離級別,包括了一些具體規則,用來限定事務內外的哪些改變是可見的,哪些是不可見的。低級別的隔離級一般支持更高的併發處理,並擁有更低的系統開銷。

Read Uncommitted(讀取未提交內容)

在該隔離級別,所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用於實際應用,因為它的性能也不比其他級別好多少。讀取未提交的數據,也被稱之為髒讀(Dirty Read)。

Read Committed(讀取提交內容)

這是大多數數據庫系統的默認隔離級別(但不是MySQL默認的)。它滿足了隔離的簡單定義:一個事務只能看見已經提交事務所做的改變。這種隔離級別 也支持所謂的不可重複讀(Nonrepeatable Read),因為同一事務的其他實例在該實例處理其間可能會有新的commit,所以同一select可能返回不同結果。

Repeatable Read(可重讀)

這是MySQL的默認事務隔離級別,它確保同一事務的多個實例在併發讀取數據時,會看到同樣的數據行。不過理論上,這會導致另一個棘手的問題:幻讀 (Phantom Read)。簡單的說,幻讀指當用戶讀取某一範圍的數據行時,另一個事務又在該範圍內插入了新行,當用戶再讀取該範圍的數據行時,會發現有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本併發控制(MVCC,Multiversion Concurrency Control)機制解決了該問題。

Serializable(可串行化)

這是最高的隔離級別,它通過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每個讀的數據行上加上共享鎖。在這個級別,可能導致大量的超時現象和鎖競爭。

這四種隔離級別採取不同的鎖類型來實現,若讀取的是同一個數據的話,就容易發生問題。例如:


  • 髒讀(Drity Read):某個事務已更新一份數據,另一個事務在此時讀取了同一份數據,由於某些原因,前一個RollBack了操作,則後一個事務所讀取的數據就會是不正確的。

  • 不可重複讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致,這可能是兩次查詢過程中間插入了一個事務更新的原有的數據。

  • 幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致,例如有一個事務查詢了幾列(Row)數據,而另一個事務卻在此時插入了新的幾列數據,先前的事務在接下來的查詢中,就有幾列數據是未查詢出來的,如果此時插入和另外一個事務插入的數據,就會報錯。


在MySQL中,實現了這四種隔離級別,分別有可能產生問題如下所示:

真正理解Mysql的四種隔離級別,看了都說好

測試Mysql的隔離級別

下面,將利用MySQL的客戶端程序,我們分別來測試一下這幾種隔離級別。

測試數據庫為demo,表為test;表結構:

真正理解Mysql的四種隔離級別,看了都說好

兩個命令行客戶端分別為A,B;不斷改變A的隔離級別,在B端修改數據。

將A的隔離級別設置為read uncommitted(未提交讀)

真正理解Mysql的四種隔離級別,看了都說好

A:啟動事務,此時數據為初始狀態

真正理解Mysql的四種隔離級別,看了都說好

B:啟動事務,更新數據,但不提交

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀取數據,發現數據已經被修改了,這就是所謂的“髒讀”

真正理解Mysql的四種隔離級別,看了都說好

B:回滾事務

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀數據,發現數據變回初始狀態

真正理解Mysql的四種隔離級別,看了都說好

經過上面的實驗可以得出結論,事務B更新了一條記錄,但是沒有提交,此時事務A可以查詢出未提交記錄。造成髒讀現象。未提交讀是最低的隔離級別。

將客戶端A的事務隔離級別設置為read committed(已提交讀)


A:啟動事務,此時數據為初始狀態

真正理解Mysql的四種隔離級別,看了都說好

B:啟動事務,更新數據,但不提交

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀數據,發現數據未被修改

真正理解Mysql的四種隔離級別,看了都說好

B:提交事務

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀取數據,發現數據已發生變化,說明B提交的修改被事務中的A讀到了,這就是所謂的“不可重複讀”

真正理解Mysql的四種隔離級別,看了都說好

經過上面的實驗可以得出結論,已提交讀隔離級別解決了髒讀的問題,但是出現了不可重複讀的問題,即事務A在兩次查詢的數據不一致,因為在兩次查詢之間事務B更新了一條數據。已提交讀只允許讀取已提交的記錄,但不要求可重複讀。

將A的隔離級別設置為repeatable read(可重複讀)


A:啟動事務,此時數據為初始狀態

真正理解Mysql的四種隔離級別,看了都說好

B:啟動事務,更新數據,但不提交

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀取數據,發現數據未被修改

真正理解Mysql的四種隔離級別,看了都說好

B:提交事務

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀取數據,發現數據依然未發生變化,這說明這次可以重複讀了

真正理解Mysql的四種隔離級別,看了都說好

B:插入一條新的數據,並提交

真正理解Mysql的四種隔離級別,看了都說好

A:再次讀取數據,發現數據依然未發生變化,雖然可以重複讀了,但是卻發現讀的不是最新數據,這就是所謂的“幻讀”

真正理解Mysql的四種隔離級別,看了都說好

A:提交本次事務,再次讀取數據,發現讀取正常了

真正理解Mysql的四種隔離級別,看了都說好

由以上的實驗可以得出結論,可重複讀隔離級別只允許讀取已提交記錄,而且在一個事務兩次讀取一個記錄期間,其他事務部的更新該記錄。但該事務不要求與其他事務可串行化。例如,當一個事務可以找到由一個已提交事務更新的記錄,但是可能產生幻讀問題(注意是可能,因為數據庫對隔離級別的實現有所差別)。像以上的實驗,就沒有出現數據幻讀的問題。

將A的隔離級別設置為可串行化(Serializable)

真正理解Mysql的四種隔離級別,看了都說好

A:啟動事務,此時數據為初始狀態

真正理解Mysql的四種隔離級別,看了都說好

B:發現B此時進入了等待狀態,原因是因為A的事務尚未提交,只能等待(此時,B可能會發生等待超時)

真正理解Mysql的四種隔離級別,看了都說好

A:提交事務

真正理解Mysql的四種隔離級別,看了都說好

B:發現插入成功

真正理解Mysql的四種隔離級別,看了都說好

serializable完全鎖定字段,若一個事務來查詢同一份數據就必須等待,直到前一個事務完成並解除鎖定為止。是完整的隔離級別,會鎖定對應的數據表格,因而會有效率的問題。

真正理解Mysql的四種隔離級別,看了都說好

歡迎在留言區留下你的觀點,一起討論提高。如果今天的文章讓你有新的啟發,學習能力的提升上有新的認識,歡迎轉發分享給更多人。


猜你還想看


阿里、騰訊、百度、華為、京東最新面試題彙集

SpringBoot2.x炫酷吊炸天前後端分離的後臺管理系統實例

再無包夜!網絡遊戲或實行宵禁,午夜之前關閉服務器,你贊同嗎?

GitHub宣佈收購npm,微軟或成最大贏家!開源界野蠻競爭影響1200萬開發者

關注訂閱號「程序員小樂」,收看更多精彩內容
嘿,你在看嗎?


分享到:


相關文章: