程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> 關於MYSQL數據庫 >> 深入解析MySQL的事務隔離及其對性能產生的影響

深入解析MySQL的事務隔離及其對性能產生的影響

編輯:關於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中,實現了這四種隔離級別,分別有可能產生問題如下所示:

20151219142625513.jpg (838×267)
MySQL事務隔離級別對其性能的影響
MySQL默認工作在級別三下。我們知道事務隔離是為了避免並發操作相互影響而導數據的不一致性。所以為了保證數據的一致性,就引入了事務隔離的功能。以上四個級別的對數據的一致性保護是逐步提高的。級別4對事務的隔離效果最好,但是性能最差,一般不再生產環境中使用。
下面通過實例來檢驗不同級別下MySQL性能收到的影響。我的實驗環境是:Redhat5.8+MySQL5.5
首先我們這裡啟用兩個session:
1、驗證級別一的特性
我們在session A上進行的操作為:

20151219142742629.jpg (439×108)

在session B上的操作同session A,這裡不再附上截圖。
       接下來我們就通過一系列的實驗來觀察READ-UNCOMMITTED到底是什麼,它到底有什麼特性,對我們的操作到底有什麼影響。首先,我們可以看到表中的初始數據如下:

20151219142759392.jpg (396×309)

接下來我們在sessionA上更改其中的一條記錄,更改結果如下:

20151219142836127.jpg (449×393)

注意:我們在上面啟用了事務,但是我們在這裡並沒有進行commit操作。
 
接下來我們在sessionB中對剛才改過的表進行select查詢,查詢結果如下:

20151219142857081.jpg (393×258)

我們可以清楚的看到,雖然我們並沒有對session A的結果進行commit,但是結果確實已經改變。因此在這種級別下,沒有提交的操作會對數據的一致性有影響。因此,如果我們此時在session A上對上述操作進行回滾,我們會發現此時session B上的結果又回到原來最初的結果,這樣就造成了數據的不一致性,這也稱為數據的幻讀現象,看起來是很詭異的事情。因此在某些場景下,我們應該避免這種現象的產生。但是這種級別也不是沒有它的用武之地,比如當我們有大量數據需要寫入,而讀操作很少的時候,就適合用這種模式。
可以看到session A回滾後,session B中的數據又變成最初的樣子,這也稱為幻讀:

20151219142930549.jpg (388×285)

2、驗證級別READ COMMITTED特性
       首先把session A和session B的隔離級別都改為READ-COMMITTED,並且全部都開啟事務,操作如下:

20151219142953399.jpg (419×106)

接下來我們查看tutors表的初始狀態信息:

20151219143009635.jpg (389×273)

然後我們依然是對數據進行更新操作,更新之後仍然沒有commit。我們可以看到在sessionA中,結果已經發生改變:

20151219143025324.jpg (447×356)

此時我們在session B中查看,發現結果依然維持不變:

20151219143041273.jpg (400×274)

但是,如果我們此時在session A中進行commit操作,我們就會發現,sessionB此時查詢就會發生改變,這樣也造成了數據的前後不一致性,也是數據的幻讀:

20151219143129621.jpg (387×272)

3、數據的可重讀
       數據的可重讀,也叫作REPEATABLE-READ,這是MySQL默認采用的事務隔離級別,有其優勢,但是仍然沒有從根本上解決數據的一致性問題。首先,還是讓我們來測試一下,在這種級別下MySQL到底是如何工作的,又有哪些特性,我們又該怎樣去操作。
       我們先把REPEATABLE-READ的環境設置好,具體的操作方法如下:

20151219143145636.jpg (426×103)

然後我們在查看其初始數據,其結果如下:

20151219143201861.jpg (391×281)

我們在session A中修改數據,並進行commit,修改後的結果如下:

20151219143219960.jpg (394×285)

然後我們在session B中進行查看發現結果仍然沒有任何改變:

20151219143235949.jpg (383×282)

這就是可重讀的特性,只要本次會話不提交,盡管對方修改,但是結果仍然不變,只有在session B中也進行commit操作,所作的修改才會在sessionB中生效。
 
4、seriabliable
這個級別是事務隔離安全性最好的,但是也是性能最差的,因為這個級別所有的操作都是串行進行的。一個操作沒有提交,另一個受到影響的操作會處於阻塞狀態。
為了驗證這種效果,我們先把環境設置好,具體為在session A和session B同時設置如下:

20151219143252378.jpg (400×100)

在session A 中對其任意字段進行修改,並且沒有進行commit操作。此時揮發現sessionB中的查詢操作會一直處於阻塞狀態:

20151219143310329.jpg (298×55)

這就設串行化隔離的效果,也是為什麼串行化隔離並發能力差的原因。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved