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(可串行化)
這是最高的隔離級別,它經過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每一個讀的數據行上加上共享鎖。在這個級別,可能致使大量的超時現象和鎖競爭。spa
這四種隔離級別採起不一樣的鎖類型來實現,若讀取的是同一個數據的話,就容易發生問題。例如:命令行
髒讀(Drity Read):某個事務已更新一份數據,另外一個事務在此時讀取了同一份數據,因爲某些緣由,前一個RollBack了操做,則後一個事務所讀取的數據就會是不正確的。排序
不可重複讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致,這多是兩次查詢過程當中間插入了一個事務更新的原有的數據。圖片
幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致,例若有一個事務查詢了幾列(Row)數據,而另外一個事務卻在此時插入了新的幾列數據,先前的事務在接下來的查詢中,就會發現有幾列數據是它先前所沒有的。事務
在MySQL中,實現了這四種隔離級別,分別有可能產生問題以下所示:get
下面,將利用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:
由以上的實驗能夠得出結論,可重複讀隔離級別只容許讀取已提交記錄,並且在一個事務兩次讀取一個記錄期間,其餘事務部的更新該記錄。但該事務不要求與其餘事務可串行化。例如,當一個事務能夠找到由一個已提交事務更新的記錄,可是可能產生幻讀問題(注意是可能,由於數據庫對隔離級別的實現有所差異)。像以上的實驗,就沒有出現數據幻讀的問題。
(四)、將A的隔離級別設置爲 可串行化 (Serializable)
A端打開事務,B端插入一條記錄
事務A端:
事務B端:
由於此時事務A的隔離級別設置爲serializable,開始事務後,並無提交,因此事務B只能等待。
事務A提交事務:
事務A端
事務B端
serializable徹底鎖定字段,若一個事務來查詢同一份數據就必須等待,直到前一個事務完成並解除鎖定爲止 。是完整的隔離級別,會鎖定對應的數據表格,於是會有效率的問題。