前言

事務一直以來是我最薄弱的環節，也是我打算重新學習SQL Server的出發點，關於SQL Server中事務將分為幾節來進行闡述，Always to review the basics。 

事務簡介

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

如果不顯式的標記事務的邊界，預設情況下，SQL Server將把每個單獨語句作為一個事務，換句話說，預設情況下，每個單獨語句結束後SQL Server自動提交事務。可以通過一個叫做IMPLICIT_TRANSACTIONS的回話選項修改SQL Server處理隱式事務的方式，此選項預設為OFF。當此選項為ON時，不需要指定BEGIN TRAN語句標記事務的開始，但是必須以COMMIT TRAN或者ROLLBACK TRAN語句標記事務的結束-摘抄自SQL Server 2012基礎教程。

事務具有原子性、一致性、隔離性、持續性四個屬性，縮寫字母為ACID。

（1）原子性：事務是一個工作單元，事務中的所有修改要麼提交、要麼撤銷，在事務完成之前如果系統出現故障，重新啟動時SQL Server會撤銷所做的修改。

（2）一致性：一致性是指資料的狀態，RDMS提供了以併發事務修改和查詢資料的能力。

（3）隔離性：隔離是用於控制訪問資料的機制，確保事務所訪問資料是在其期望的一致性級別中的資料，SQL Server支援兩種不同的模式來處理隔離：基於鎖的傳統模式和基於行版本控制的新模式，在企業內部部署的SQL Server中，預設是基於鎖的模式。

（4）持續性：資料修改寫入到資料庫磁碟上的資料部分之前，總是先寫入到資料庫的事務日誌磁碟，在提交之後，指令記錄在事務日誌的磁碟上，在尚未修改磁碟上的資料部分之前，事務被認為是持續的，在系統正常或是出現故障啟動時，SQL Server將檢查每個資料庫的事務日誌並執行具有兩個階段的恢復過程-重做和撤銷。可以用如下圖表示四個事務屬性。

圖片來源：https://blog.sqlauthority.com/2007/12/09/sql-server-acid-atomicity-consistency-isolation-durability/

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

排他鎖：當試圖修改資料時，事務會請求資料資源的一個排他鎖，而不管其隔離級別，如果授予了鎖，那麼排他鎖知道事務結束才會被解除，對於單語句事務意味著直到語句完成鎖定才會被解除，對於多語句事務意味著直到完成所有語句並通過COMMIT TRAN或ROLLBACK TRAN命令結束才會解除鎖定。排他鎖之所以被稱為排他，是因為如果一個事務正在修改行，直到事務完成，其他事務都不能修改相同的行，這是預設的修改行為。然而，另外一個事物能不能讀取相同的行，取決於它的隔離級別。

共享鎖：當試圖讀取資料時，事務預設請求資料資源的一個共享鎖，並且一旦語句完成資源讀取，會立即釋放資源的共享鎖。共享鎖之所以被稱為共享，是因為多個事務可以同時持有相同資源的共享鎖。雖然在修改資料時，不能修改鎖的模式和所需的持續時間，但是通過改變其隔離級別，可以在讀取資料時控制鎖定的處理方式。

講述了鎖的兩種重要的模式，那麼問題來了，鎖的存在會導致什麼問題？請繼續往下看。我們試圖去更新一條資料，此時並未進行提交

BEGIN TRAN

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2

接下來我們再來讀取該條記錄的資料。

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

接下來我們進行查詢，此時會發現一直在查詢中直到達到設定的查詢超時時間為止。

當更新行時會獲取該資源上的排他鎖，如果更新成功，SQL Server會將鎖授予會話，所以直到事務完成，其排他鎖會一直存在，當讀取資料時需要獲取該資源上的共享鎖，但是更新行會話一直存在即以排他鎖鎖定，但是排他鎖和共享鎖不能相容，此時會導致查詢阻塞不得不進行等待。說明鎖在併發情況下會導致阻塞。那麼是不是不加鎖就萬事大吉了呢？我們繼續往下看。

鎖的隔離級別

隔離級別確定了併發使用者讀取或寫入的行為，讀取者是任何選擇資料的語句，預設情況下使用共享鎖，寫入者是任何對錶進行修改的語句，並且需要一個排他鎖。在獲得鎖和鎖的持續期間，不能控制寫入者的行為方式，但是可以控制讀取者的行為方式，我們通過設定隔離級別來隱式的影響寫入者的行為。

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的樂觀併發對應方式。

我們使用如下命令來設定整個會話的隔離級別

SET TRANSACTION ISOLATION LEVEL <isolation name>

或者間接在表查詢中設定查詢的隔離級別。

SELECT ....  FROM TABLE WITH(<isolationname>)

對於以上四個隔離級別，隔離級別越高，讀取者請求的鎖就越強，並且持續時間越長。因此，隔離級別越高，一致性越高並且性越低，當然，反過來也是如此。對於兩個基於快照的隔離級別，SQL Server能夠在tempdb中儲存之前提交的行版本，讀取者不請求共享鎖。相反，如果當前的行版本不是他們應該看到的，SQL Server將提供給他們一個較舊的版本。

READ UNCOMMITTED隔離級別

READ COMMITTED是最低隔離級別，在該隔離級別中，讀取者不需要請求共享鎖，不要求共享鎖的讀取者從不會與持有排他鎖的寫入者發生衝突，這意味著讀取者可以讀取未提交的更改即髒讀，也就是說，讀取者不會干擾要求了排他鎖的寫入者，在該隔離級別下執行的讀取者讀取資料時，寫入者可以更改資料。

上述我們圈出此時productid = 2的行記錄，此時我們來更新該條行記錄的uniprice列資料，如下

BEGIN TRAN

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2;

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

此時我們清楚看到上述單價（unitprice）更新為了25，沒毛病，此時我們再設定隔離級別為READ UNCOMMITTED執行如下程式碼（我們保持上述更新會話一直開啟，此時將保持排他鎖一直存在，雖然排他鎖和貢獻鎖不相容，但是在READ COMMITTED隔離級別下查詢不會去請求共享鎖，所以並不會與上述更新事務衝突）

SET TRAN ISOLATION LEVEL READ UNCOMMITTED

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

此時我們再將上述未提交的值進行回滾，如下

BEGIN TRAN

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2;

ROLLBACK TRAN

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

到這裡我們想必知道了髒讀的由來，當我們在一個會話中更新指定行記錄時，此時我們並未進行提交，此時unitprice更新為25，接著我們在READ COMMITTED隔離級別下去查詢同一行記錄此時查詢unitprice為25（即使上述修改並未進行提交），最後我們在某一時刻通過回滾對更新事務進行了撤銷，此時資料庫中的該行記錄依然是24，但是我們讀取的結果卻是25，所以 讀取者獲得的是從未提交過的值，也就是我們說的髒讀。到這裡我們可以下一個結論：

READ UNCOMMITTED：在該隔離級別下會導致資料髒讀。

我們通過設定隔離級別為READ COMMITTED來解決資料髒讀，請繼續往下看。

READ COMMITTED隔離級別

如果想阻止讀取者未提交的修改，則需要使用更高的隔離級別，防止髒讀的最低的隔離級別為READ COMMITTED，它是企業內部部署的SQL Server預設隔離級別，如名稱所述，該隔離級別僅允許讀取者已提交的更改。它通過要求讀取者獲得一個共享鎖來防止未提交的讀取，也就是說，如果一個寫入者持有了排他鎖，讀取者的共享鎖請求將會與寫入者衝突，此時必須等待，一旦寫入者提交了事務，讀取者就可以獲得它的共享鎖，所以它必然是隻讀取提交後的修改。關於READ COMMITTED隔離級別的示例上述我們已經演示。

問題1：與READ COMMITTED隔離級別不同的是，在READ COMMITTED隔離級別中，不會獲得髒讀，因為它只能讀取已提交的修改，但是寫入者未進行提交此時會導致持續等待，對於讀取者直到完成，讀取者都僅持有共享鎖，它不會到事務結束一直持有鎖，它甚至不會到語句結束，換句話說，在同一事務中的兩次相同資料資源的讀取之間，不會持有該資源的鎖，所以其他事務可以在這兩次讀取的間隙修改資源，並且讀取者每次讀取到的值可能會有所不同，這種現象被稱為不可重複讀取或不一致解析。此時我們就必須通過更高的隔離級別來解決不可重複讀取的問題。

問題2：同時我們需要注意的是在READ COMMITTED隔離級別中可能出現【丟失更新】現象，丟失更新主要發生在兩個事務讀取一個值時，同時基於讀取的值進行更新，由於在該隔離級別中讀取後不會再該資源上持有鎖，兩個事務都可以更新其值，並且最後更新該值的事務將會覆蓋另外一個事務的更新。

REPEATABLE READ隔離級別

如果我們希望確保在同一事務中的多次讀取之間沒有其他事務能夠修改其值，需要提升隔離級別到REPEATABLE READ。在該隔離級別中，讀取者不僅需要一個共享鎖才能夠進行讀取，而且直到事務結束都持有鎖，這意味著只要讀取者獲得了資料資源上的共享鎖，直到讀取者結束事務，都沒有其他事務可以獲取一個排他鎖來修改資源，這樣才能保證可重複讀取或者是一致的解析。我們來演示下該隔離級別，如下：

SET TRAN ISOLATION LEVEL REPEATABLE READ

BEGIN TRAN

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

此時返回productid = 2的單價。接下來我們再來進行更新。

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2;

由於寫入者請求的排他鎖與授予讀取者的共享鎖衝突，此時寫入者事務會被阻塞，如果讀取者是執行在READ UNCOMMITTED或者READ COMMITTED隔離級別下，此時它將不會持有共享鎖，並且試圖修改該行就會成功。當我們在查詢事務中新增COMMIT TRAN，此時讀取者的事務已經提交併且釋放了共享鎖，如下：

SET TRAN ISOLATION LEVEL REPEATABLE READ

BEGIN TRAN

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

COMMIT TRAN

此時再來寫入者就能獲取等待它的排他鎖並且成功更新行，此時unitprice = 25；

問題1：雖然REPEATABLE READ隔離級別能夠確保同一事務中的多次讀取沒有其他事務來修改值即解決了不可重複讀取或不一致解析的問題，但是在第一次讀取後雙方都會保持它們的共享鎖，因此對於稍後的更新都不會獲得一個排他鎖，這樣就很有可能導致死鎖，並且阻止更新衝突。

問題2：雖然REPEATABLE READ隔離級別可以確保在事務中第一次讀取的行能夠重複讀取，但是事務鎖定的資源（如行）是查詢第一次執行時發現的，在查詢執行時那裡並沒有行，因此，同一事務中的第二次讀取可能會返回新行，這些新行被稱為幻影，這種讀取稱為幻影讀取，如果在讀取之間，另一個事務添加了讀取者查詢篩選限定的新行，就會導致幻影讀取。

既然REPEATABLE READ容易導致幻影讀取，我們則需要更高的隔離級別來解決這個問題，請繼續往下看。

SERIALIZABLE隔離級別

為了防止幻影讀取，需要將隔離級別提升為SERIALIZABLE，最重要的部分是SERIALIZABLE隔離級別的行為類似於REPEATABLE READ即它要求讀取者獲取一個共享鎖來進行讀取，並持有鎖到事務結束，但是SERIALIZABLE隔離級別添加了另外一個方面-在邏輯上，該隔離級別要求讀取者鎖定查詢篩選所限定的鍵的整個範圍。這意味著讀取者鎖定的不僅是查詢篩選限定的現有行，也包括將來行，或者準確地說，它會阻止其他事務嘗試新增讀取者查詢篩選限定的行。下面我們來演示這種情況。

BEGIN TRAN

SELECT 
    productid, productname, categoryid, unitprice
FROM Production.Products
WHERE categoryid = 1

我們查詢產品Id = 1的所有行，結果集如下：

接下來我們再來插入一條資料。

INSERT INTO Production.Products
        ( productname ,
          supplierid ,
          categoryid ,
          unitprice ,
          discontinued
        )
VALUES  ( N'Product ABCDE' , -- productname - nvarchar(40)
          1 , -- supplierid - int
          1 , -- categoryid - int
          20.00 , -- unitprice - money
          0  -- discontinued - bit
        )

此時嘗試插入會成功，但是查詢出來的資料有12條資料，實際上有13條資料也就是說導致幻影讀取。當我們在查詢資料時設定SERIALIZABLE如下隔離級別，此時插入語句會將處於阻塞狀態

SET TRAN ISOLATION LEVEL SERIALIZABLE

通過設定隔離級別為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隔離級別

在SNAPSHOT隔離級別下，讀取者在讀取資料時， 它是確保獲得事務啟動時最近提交的可用行版本，這意味著，保證獲得的是提交後的讀取並且可重複讀取，以及確保獲得不是幻讀，類似於SERIALIZABLE級別中一樣，但是此隔離級別依賴於行版本，而不是使用共享鎖，要想在企業部署的SQL Server例項中允許事務以SNAPSHOT隔離級別工作，首先需要在查詢視窗執行以下程式碼開啟快照隔離級別。如下：

ALTER DATABASE TSQL2012 SET ALLOW_SNAPSHOT_ISOLATION ON

下面來演示SNAPSHOT隔離級別行為，我們開啟一個事務在當前基礎上更新單價，如下：

BEGIN TRAN

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2;


SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

此時更新尚未提交的事務，此時其單價為25。

SET TRAN ISOLATION LEVEL SNAPSHOT

BEGIN TRAN

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

因為我們在資料庫中啟用了SNAPSHOT隔離級別，此時即使是在READ COMMITTED隔離級別下執行也會複製更新到tempdb之前的版本，如下我們設定隔離級別為SNAPSHOT來開啟一個事務查詢其行記錄。

SET TRAN ISOLATION LEVEL SNAPSHOT

BEGIN TRAN

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

如果是在SERIALIZABLE隔離級別下執行，此時肯定導致查詢阻塞，但是由於在SNAPSHOT模式下，不會去獲取該事務上的共享鎖，而是獲取事務執行時可用的上次提交的行版本。此時之前版本的unitprice = 24而不是當前版本的unitprice = 25，如下：

此時我們再將上述未提交的寫入事務進行提交。此時unitprice = 25的當前版本則變為了提交版本，但是我們再來讀取資料並提交事務，仍舊會獲得該行事務啟動時可用的最後提交版本，如下：

當我們重新開啟一個事務進行查詢，此時事務啟動時該行可用的最後提交版本時unitprice = 25的版本，如下：

SNAPSHOT隔離級別可以防止更新衝突，但不會像REPEATABLE READ和SERIALIZABLE隔離級別那樣產生死鎖，SNAPSHOT隔離級別的事務失敗，表明檢測到了更新衝突，SNAPSHOT隔離級別通過檢查儲存的版本來檢測更新衝突，它可以發現在事務的讀取和寫入之間是否有另一個事務修改了資料。

READ COMMITTED SNAPSHOT隔離級別

該隔離級別也是基於行版本控制，它與SNAPSHOT隔離級別區別在於，讀取者獲得是【語句】啟動時可用的最後提交的行版本，而不是【事務】啟動時可用的最後提交的行版本，READ COMMITTED SNAOSHOT也不會檢測更新衝突，導致類似於READ COMMITTED隔離級別，但在所請求資源以排他鎖鎖定時，不會請求共享鎖並且不會等待。在企業內部部署的SQL Server中要想啟動READ COMMITTED SNAPHOST隔離級別，需要開啟唯一會話來設定，否則無法進行啟用（啟用該隔離級別實際上是將READ COMMITTED隔離級別在語義上改變為READ COMMITTED SNAPSHOT隔離級別）。下面我們來演示下READ COMMITTED SNAPSHOT隔離級別。

ALTER DATABASE TSQL2012 SET READ_COMMITTED_SNAPSHOT ON;

我們同樣是更新一個尚未提交的事務，如下：

BEGIN TRAN;

UPDATE Production.Products
    SET unitprice += 1.00
WHERE productid = 2;

SELECT 
    productid, unitprice
FROM Production.Products
WHERE productid = 2

此時我們將上述寫入進行提交，再來開啟一個會話讀取該行記錄資料。

此時我們再來提交事務看看。

如果 是在SNAPSHOT隔離級別下執行上述程式碼，就會得到unitprice = 24，但是由於程式碼執行在READ COMMITTED SNAPSHOT隔離級別下，會得到語句啟動時可用的最後提交的行版本unitprice = 25，而不是事務開始時的行版本unitprice = 24。

總結

本節比較詳細的討論了事務、四種悲觀式併發隔離級別和兩種樂觀式併發隔離級別，下節我們開始談論一些細枝末節。