MySQL交易隔離等級詳解

來源:互聯網
上載者:User

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

Read Uncommitted(讀取未提交內容)

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


Read Committed(讀取提交內容)

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


Repeatable Read(可重讀)

       這是MySQL的預設交易隔離等級,它確保同一事務的多個執行個體在並發讀取資料時,會看到同樣的資料行。不過理論上,這會導致另一個棘手的問題:幻讀 (Phantom Read)。簡單的說,幻讀指當使用者讀取某一範圍的資料行時,另一個事務又在該範圍插入入了新行,當使用者再讀取該範圍的資料行時,會發現有新的“幻影” 行。InnoDB和Falcon儲存引擎通過多版本並發控制(MVCC,Multiversion
Concurrency Control)機制解決了該問題。

鎖定行,可以控制update和delete操作的提交後的顯示問題,但是insert操作的提交後的結果,無法控制。


Serializable(可序列化) 

       這是最高的隔離等級,它通過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每個讀的資料行上加上共用鎖定???(是嗎?)在這個層級,可能導致大量的逾時現象和鎖競爭。

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

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

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

         幻讀(Phantom Read):在一個事務的兩次查詢中資料筆數不一致,例如有一個事務查詢了幾列(Row)資料,而另一個事務卻在此時插入了新的幾列資料,先前的事務在接下來的查詢中,就會發現有幾列資料是它先前所沒有的。這個問題只是有可能出現,因為實現方法不同,有的也不會出現。

而且新添加資料可能會出現,修改資料不會。


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


下面,將利用MySQL的用戶端程式,分別測試幾種隔離等級。測試資料庫為test,表為tx;表結構:

id                               int

num

                              int

兩個命令列用戶端分別為A,B;不斷改變A的隔離等級,在B端修改資料。

(一)、將A的隔離等級設定為read uncommitted(未提交讀)

 在B未更新資料之前:

用戶端A:

B更新資料:

用戶端B:

用戶端A:

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


(二)、將用戶端A的交易隔離等級設定為read committed(已提交讀)

 在B未更新資料之前:

用戶端A:

B更新資料:

用戶端B:

用戶端A:

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


(三)、 將A的隔離等級設定為repeatable read(可重複讀)

 在B未更新資料之前:

用戶端A:

B更新資料:

用戶端B:

用戶端A:



B插入資料:

用戶端B:

用戶端A:

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



( 四)、將A的隔離等級設定為 可序列化 (Serializable)

A端開啟事務,B端插入一條記錄

事務A端:

事務B端:

因為此時事務A的隔離等級設定為serializable,開始事務後,並沒有提交,所以事務B只能等待。

事務A提交事務:

事務A端

事務B端

      

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



轉載 http://xm-king.iteye.com/blog/770721


相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.