sqlserver事務隔離

事務是一個工做單元，可能包含查詢和修改數據以及修改數據定義等多個活動。咱們能夠顯式或隱式的定義事務邊界。可使用BEGIN TRAN或者BEGIN TRANSACTION語句顯式的定義事務的開始。若是但願提交事務，可使用COMMIT TRAN語句顯式的定義事務結束。若是不但願提交事務（即要撤銷更改），可使用ROLLBACK TRAN或者ROLLBACK TRANSACTION語句-摘抄自SQL Server 2012基礎教程。

若是不顯式的標記事務的邊界，默認狀況下，SQL Server將把每一個單獨語句做爲一個事務，換句話說，默認狀況下，每一個單獨語句結束後SQL Server自動提交事務。

說到事務就聯想到併發，爲了解決事務中的併發咱們則不得不討論下鎖，因此接下來咱們首先熟悉一下鎖的模式-排他鎖和共享鎖。

先看看下面的試驗，先開始一個事務處理，這個事務不提交也不回滾，而後另外在打開一個窗口查詢數據。

在上面的事務沒有提交也沒有回滾的狀況下，若是另外一個程序在執行查詢，那麼就會阻塞，若是沒有設置查詢超時，就會一直等待。

緣由：當事務會話對錶進行修改（增刪改）時，事務會請求數據資源的一個排他鎖，這個鎖直到事務完成（提交或者回滾）纔會被取消。當讀取數據時須要獲取該資源上的共享鎖，可是排他鎖和共享鎖不能兼容，此時會致使查詢阻塞不得不進行等待。

就上面的試驗，第一個事務擁有排它鎖，在事務沒有完成的狀況下，第二個事務攜帶共享鎖來訪問表，此時就必須等待第一個事務完成後才能進行查詢。可是反過來沒問題，就是先有查詢的事務進行查詢，可是沒完成事務，而後第二個事務來進行修改

而且能正常完成事務（這主要是由於在默認的隔離級別下，共享鎖在完成數據的讀取後就釋放了，而不是在事務會話完成後釋放）。注意，這個鎖是針對修改的數據的行的，不是針對整個表。好比上面修改的是id=1的行，但若是我查詢id=2的行，那麼就不會出現阻塞。

所以，在事務處理中，若是遇到併發的狀況，會有可能致使程序阻塞。

 

鎖的隔離級別

SQL Server支持4個基於悲觀併發控制的傳統隔離級別：

　　READ UNCOMMITTED、

　　READ COMMITTED（企業內部部署的SQL Server實例的默認方式）、

　　REPEATABLE READ、

　　SERIALIZABLE。

SQL Server還支持兩種基於併發控制（行版本）的隔離級別：

　　SNAPSHOT

　　READ COMMITTED SNAPSHOT（SQL Database的默認方式）

在某種意義上，SNAPSHOT和READ COMMITTED SNAPSHOT分別是READ COMMITTED和SERIALIZABLE的樂觀併發對應方式。

 

第一類丟失更新：撤銷一個事務時，把其餘事務已提交的更新數據覆蓋。

髒讀：一個事務讀到另外一事務未提交的更新數據。

虛讀：一個事務讀到另外一事務已提交的新插入的數據。

不可重複讀：一個事務讀到另外一事務已提交的更新數據。

第二類丟失更新：這是不可重複讀中的特例，一個事務覆蓋另外一事務已提交的更新數據。

 

READ UNCOMMITTED隔離級別

READ UNCOMMITTED是最低隔離級別，在該隔離級別中，讀取者不須要請求共享鎖，不要求共享鎖的讀取者從不會與持有排他鎖的寫入者發生衝突，這意味着讀取者能夠讀取寫入者未提交的更改即髒讀，也就是說，讀取者不會干擾要求了排他鎖的寫入者，在該隔離級別下運行的寫入者更改數據時，讀取者能夠讀取數據。

 默認狀況下，上面的語句執行成功的，可是事務沒有執行完成，這時排它鎖是存在的，下面在另外一個事務中設置隔離級別爲READ UNCOMMITTED運行以下代碼，能夠看到，這個事務能查詢到上一個事務沒有提交的修改

 

這時候咱們再將第一個事務回滾（只執行紅框中的語句）。

 

能夠看到在隔離級別是READ UNCOMMITTED的狀況下，事務併發會出大問題的（第二個事務獲取了一個錯誤的數據）。

 

READ COMMITTED隔離級別

 該隔離級別僅容許讀取已提交的更改。它經過要求讀取者得到一個共享鎖來防止未提交的讀取，也就是說，若是一個寫入者持有了排他鎖，讀取者的共享鎖請求將會與寫入者的排它鎖衝突，此時必須等待，一旦寫入者提交了事務，讀取者就能夠得到它的共享鎖，因此它必然是隻讀取提交後的修改。這個已經在本文最開始的時候試驗過了。

這裏再次試驗一下：虛讀

在第一個事務中，第一次查詢得到了6條數據，這時候事務未提交，開始第二個事務

成功提交後，繼續執行第一個事務的第二次查詢，

 

不可重複讀和上面的試驗相似，只是變成的修改。可是對於虛讀，我一直沒理解真實的場景中有什麼問題。看了不少介紹，都說在同一個事務中，兩次相同條件的查詢得到的結果不一樣，就是虛讀或者不可重複讀，可是這樣的狀況在實際場景

中是很合理的啊。因此有點不明白。不少介紹中說是，在同一個事務中，兩次查詢得到的結果不一致（注意，對於虛讀的定義是兩次查詢，包括不可重複讀也是，可是不少介紹銀行取款存款的例子中，只有一次查詢），會致使用戶沒法肯定該

用哪一個結果，可是咱們假設兩次讀取的數據都是真實的，那麼之後面讀取的數據爲準，這樣是符合事實邏輯的啊，

就是不明白這種狀況爲何會有問題，在實際場景中也想不出這樣的問題在哪裏。思來想去，以爲在真實場景中由於這虛讀或不重複讀出現問題的可能就是一種很極端的狀況：

在特定時刻下，須要對錶中id<10的數據進行一次刪除或者其餘的一些處理吧，反正就是要對此刻之前在表中知足必定條件的數據進行處理。所以在事務1中，第一次查詢得到了此刻，在表中知足條件的數據。而後這時，另外一個事務添加了

一條也知足這個條件的數據（或者是對知足條件的數據進行了修改）。那麼在繼續進行事務1的處理（好比刪除或者其餘的一些操做），就會將事務2添加的數據（或者修改的數據）一併給處理了，可是，事務2添加的數據是在特定時刻之後纔出現的，是不能

被處理的。固然這樣的狀況是確實有可能發生，可是爲了不這樣的狀況，相信在寫sql語句的時候有不少辦法來避免的。

在此隔離級別下要注意一種狀況，就是：事務1有兩個相同的查詢，在剛執行完第一次查詢後，事務2在這個時候對查詢的數據進行了修改，而且提交了。那麼事務1的第二個查詢獲取的數據就是新的數據。這一切看起來很正常，可是要注意的是，在事務1的兩個

相同查詢中得到了不一樣的數據，這種狀況看似合理，但實則是每次讀取到的值可能會有所不一樣，這種現象被稱爲不可重複讀取或不一致解析，即既是虛讀，又是不可重複讀取。

更進一步則是在事務1中的第二次查詢後，根據查詢的結果來修改數據，而且成功提交了，這就是第二類更新丟失了。

REPEATABLE READ隔離級別

若是要解決虛讀的問題，至少將隔離級別調到repeatable read。

看下面的試驗，將隔離級別設置爲repeatable read，在執行查詢後，沒有完成事務

接着在另外一個窗口中執行下面的修改事務，會看到事務一直在等待執行。這時候將上面的事務若是還有第二次讀取，那麼讀取的結果和第一次確定是相同的，由於沒有被其餘事務修改。提交或回滾後，下面的事務就當即執行 

 經過這個試驗能夠看到， REPEATABLE READ隔離成功解決了不可重複讀的問題，同時也解決了第二類更新丟失的問題。

 可是這個隔離會出現死鎖的狀況，看下面的試驗：

事務中先執行查詢，再執行修改

 

能夠看到，這裏死鎖了，一直在執行，即便先修改後查詢也是同樣。緣由：在這種隔離下，查詢的時候會獲取一個共享鎖，這個共享鎖必須直到事務完成後才釋放（前面兩種隔離不會這樣），而後遇到了修改語句，須要獲取一個排它鎖，可是排他鎖和

共享鎖不能同時存在，所以就一直等着，死鎖了。（前面兩種隔離，若是在同一個事務中，先有修改，再有查詢，那麼也會形成死鎖）

 

還有一個問題，看下面的試驗：

先執行事務：執行紅框中的部分，表示這個事務只執行了一個查詢，查詢結果以下

而後第二個事務來了：這個能成功執行，由於第一個事務的共享鎖是鎖定了id爲1到6的行，可是id=8的行沒有鎖住，因此能夠得到這行的排它鎖。（不知道這樣理解對不對）

而後繼續執行第一個事務的後面部分，查詢結果

 

能夠看到，同一個事務的兩次一樣的查詢，得到了不一樣的結果，這就是虛讀。

 

ERIALIZABLE隔離級別

爲了防止幻影讀取，須要將隔離級別提高爲SERIALIZABLE，最重要的部分是SERIALIZABLE隔離級別的行爲相似於REPEATABLE READ即它要求讀取者獲取一個共享鎖來進行讀取，並持有鎖到事務結束，可是SERIALIZABLE隔離級別添加了另一個方面-在邏輯上，該隔離級別要求讀取者鎖定查詢篩選所限定的鍵的整個範圍。這意味着讀取者鎖定的不只是查詢篩選限定的現有行，也包括未來行，或者準確地說，它會阻止其餘事務嘗試添加讀取者查詢篩選限定的行。

基於行版本的隔離級別

在SQL Server中存在兩種基於行版本控制技術的隔離級別：SNAPSHOT、READ COMMITTED SNAPSHOT。將提交行以前的版本存儲在tempdb中，SNAPSHOT隔離級別在邏輯上相似於SERIALIZABLE隔離級別，READ COMMITTED SNAPSHOT隔離級別相似於READ COMMITTED隔離級別，可是，讀取者使用基於行版本控制的隔離級別並不不會發出共享鎖，因此在請求的數據以排他鎖鎖定時它們不會等待，讀取者仍舊會得到相似於SERIALIZABLE和READ  COMMITTED的一致性級別，若是當前版本不是它們但願看到的版本，那麼SQL Server會給讀取者提供一個較舊的版本。

若是啓用了任何基於快照的隔離級別，在修改tempdb以前，DELETE和UPDATE語句須要複製行的版本，對於INSERT語句則不須要再tempdb中版本化，由於它不存在早期的版本，但須要注意的是，啓用任何基於行版本控制的隔離級別對於數據更新和刪除的性能可能會有負面影響，因爲它們不會獲取共享鎖，而且哎數據被以排他方式鎖定或是數據版本不是所指望的版本時不須要等待，所以對於讀取者的性能一般會有所改善。

 

SNAPSHOT隔離級別

要想在企業部署的SQL Server實例中容許事務以SNAPSHOT隔離級別工做，首先須要在查詢窗口執行如下代碼打開快照隔離級別。以下：tsql2012是數據庫名

ALTER DATABASE TSQL2012 SET ALLOW_SNAPSHOT_ISOLATION ON

下面經過試驗來看看SNAPSHOT的行爲：

執行下面的 事務，事務未完成。這若是沒有執行剛纔的alert語句，這個事務是會死鎖的，緣由上面已經解釋過了

 

而後另外一個事務：

 

從查詢結果看，獲取的數據是第一個事務修改前的數據。而後如今將第一個事務提交，再來看看第二個事務的後半部分的查詢結果

 看到，只要第二個事務沒有提交，那麼它無論進行多少次查詢，得到的結果都是同樣的

 

 

 

 SNAPSHOT隔離級別能夠防止更新衝突，但不會像REPEATABLE READ和SERIALIZABLE隔離級別那樣產生死鎖，SNAPSHOT隔離級別的事務失敗，代表檢測到了更新衝突，SNAPSHOT隔離級別經過檢查存儲的版原本檢測更新衝突，它能夠發如今事務的讀取和寫入之間是否有另外一個事務修改了數據。

READ_COMMITTED_SNAPSHOT隔離級別

該隔離級別也是基於行版本控制，它與SNAPSHOT隔離級別區別在於，讀取者得到是【語句】啓動時可用的最後提交的行版本，而不是【事務】啓動時可用的最後提交的行版本，READ_COMMITTED_SNAPSHOT也不會檢測更新衝突，致使相似於READ COMMITTED隔離級別，但在所請求資源以排他鎖鎖定時，不會請求共享鎖而且不會等待。在企業內部部署的SQL Server中要想啓動READ_COMMITTED_SNAPSHOT隔離級別，須要打開惟一會話來設置，不然沒法進行啓用（啓用該隔離級別其實是將READ COMMITTED隔離級別在語義上改變爲READ_COMMITTED_SNAPSHOT隔離級別）。要啓用該隔離級別，須執行以下語句：

ALTER DATABASE TEST SET SINGLE_USER WITH ROLLBACK IMMEDIATE   --數據庫置爲單用戶模式
ALTER DATABASE TEST SET READ_COMMITTED_SNAPSHOT ON

用這種隔離級別將事務處理完成後，記得要將數據庫重置爲多用戶模式，而且關閉這種隔離

ALTER DATABASE TEST set MULTI_USER

ALTER DATABASE TEST SET READ_COMMITTED_SNAPSHOT OFF

這個在試驗的時候，無法在同一個窗口打開兩個不一樣的事務，因此無法驗證了。