SQL事務隔離級別

資料庫是要被廣大客戶所共用訪問的，那麼在資料庫操作過程中很可能出現以下幾種不確定情況。

更新丟失（Lost update）

　　兩個事務都同時更新一行數據，但是第二個事務卻中途失敗退出，導致對數據的兩個修改都失效了。這是因為系統沒有執行任何的鎖操作，因此併發事務並沒有被隔離開來。

臟讀（Dirty Reads）

　　一個事務開始讀取了某行數據，但是另外一個事務已經更新了此數據但沒有能夠及時提交。這是相當危險的，因為很可能所有的操作都被回滾。

不可重覆讀（Non-repeatable Reads）

　　一個事務對同一行數據重覆讀取兩次，但是卻得到了不同的結果。它包括以下情況：

　　（1） 事務T1讀取某一數據後，事務T2對其做了修改，當事務T1再次讀該數據時得到與前一次不同的值。

　　（2） 幻讀（Phantom Reads）：事務在操作過程中進行兩次查詢，第二次查詢的結果包含了第一次查詢中未出現的數據或者缺少了第一次查詢中出現的數據（這裡並不要求兩次查詢的SQL語句相同）。這是因為在兩次查詢過程中有另外一個事務插入數據造成的。

　　● 未授權讀取（讀未提交）（Read Uncommitted）：允許臟讀取，但不允許更新丟失。如果一個事務已經開始寫數據，則另外一個數據則不允許同時進行寫操作，但允許其他事務讀此行數據。該隔離級別可以通過“排他寫鎖”實現。

　　● 授權讀取（讀提交）（Read Committed）：允許不可重覆讀取，但不允許臟讀取。這可以通過“瞬間共用讀鎖”和“排他寫鎖”實現。讀取數據的事務允許其他事務繼續訪問該行數據，但是未提交的寫事務將會禁止其他事務訪問該行。

　　● 可重覆讀取（Repeatable Read）：禁止不可重覆讀取和臟讀取，但是有時可能出現幻影數據。這可以通過“共用讀鎖”和“排他寫鎖”實現。讀取數據的事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。

　　● 序列化（Serializable）：提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接著一個地執行，但不能併發執行。如果僅僅通過“行級鎖”是無法實現事務序列化的，必須通過其他機制保證新插入的數據不會被剛執行查詢操作的事務訪問到。

　　隔離級別越高，越能保證數據的完整性和一致性，但是對併發性能的影響也越大。對於多數應用程式，可以優先考慮把資料庫系統的隔離級別設為Read Committed，它能夠避免臟讀取，而且具有較好的併發性能。儘管它會導致不可重覆讀、虛讀和第二類丟失更新這些併發問題，在可能出現這類問題的個別場合，可以由應用程式採用悲觀鎖或樂觀鎖來控制。

事務的隔離級別

SQL Server通過在鎖資源上使用不同類型的鎖來隔離事務。為了開發安全的事務，定義事務內容以及應在何種情況下回滾至關重要，定義如何以及在多長時間內在事務中保持鎖定也同等重要。這由隔離級別決定。應用不同的隔離級別，SQL Server賦予開發者一種能力，讓他們為每一個單獨事務定義與其他事務的隔離程度。事務隔離級別的定義如下：

· 是否在讀數據的時候使用鎖

· 讀鎖持續多長時間

· 在讀數據的時候使用何種類型的鎖

· 讀操作希望讀已經被其他事務排他鎖住的數據時，怎麼辦？在這種情況下，SQL Server可以：

· 一直等到其他事務釋放鎖

· 讀沒有提交的數據

· 讀數據最後提交後的版本

ANSI 99定義了4種事務隔離級別，SQL Server 2005能夠完全支持這些級別：

· 未提交讀 在讀數據時不會檢查或使用任何鎖。因此，在這種隔離級別中可能讀取到沒有提交的數據。

· 已提交讀 只讀取提交的數據並等待其他事務釋放排他鎖。讀數據的共用鎖在讀操作完成後立即釋放。已提交讀是SQL Server的預設隔離級別。

· 可重覆讀 像已提交讀級別那樣讀數據，但會保持共用鎖直到事務結束。

· 可序列化 工作方式類似於可重覆讀。但它不僅會鎖定受影響的數據，還會鎖定這個範圍。這就阻止了新數據插入查詢所涉及的範圍，這種情況可以導致幻像讀。

此外，SQL Server還有兩種使用行版本控制來讀取數據的事務級別(本章後文將詳細檢驗這些隔離級別)。行版本控制允許一個事務在數據排他鎖定後讀取數據的最後提交版本。由於不必等待到鎖釋放就可進行讀操作，因此查詢性能得以大大增強。這兩種隔離級別如下：

· 已提交讀快照 它是一種提交讀級別的新實現。不像一般的提交讀級別，SQL Server會讀取最後提交的版本並因此不必在進行讀操作時等待直到鎖被釋放。這個級別可以替代提交讀級別。

· 快照 這種隔離使用行版本來提供事務級別的讀取一致性。這意味著在一個事務中，由於讀一致性可以通過行版本控制實現，因此同樣的數據總是可以像在可序列化級別上一樣被讀取而不必為防止來自其他事務的更改而被鎖定。

無論定義什麼隔離級別，對數據的更改總是通過排他鎖來鎖定並直到事務結束時才釋放。

很多情況下，定義正確的隔離級別並不是一個簡單的決定。作為一種通用的規則，要選擇在儘可能短的時間內鎖住最少數據，但同時依然可以為事務提供它所需的安全程度的隔離級別。

已提交讀

在SQL Server 2005中，已提交讀隔離級別是建立連接時的預設隔離級別。這個級別存在兩種類型：已提交讀和已提交讀快照隔離級別。應用哪種類型由資料庫選項定義。已提交讀級別會在讀數據之前等待，直到阻塞鎖被釋放。已提交讀快照級別會在數據被其他事務阻塞時使用行版本控制來讀數據最後一次提交的版本。

使用已提交讀級別：

BEGIN TRAN

SELECT

    FirstName, LastName, EmailAddress

FROM

    Person.Contact

WHERE

ContactID = 1

    返回EmailAddress為[email protected]的聯繫人Gustavo Achong。

現在假設另一事務在事務打開狀態下更改了EmailAddress。打開第二個查詢視窗並執行以下批來UPDATE EmailAddress，但不提交事務：

USE AdventureWorks;

BEGIN TRAN

UPDATE

    Person.Contact

SET

    EmailAddress = '[email protected]'

WHERE

    ContactID = 1

    這個UPDATE 語句會正常運行。一行受到了影響，即使數據在這個事務還沒有運行完之前已被查詢視窗1中的事務讀取。因為已提交讀級別並不會在事務結束前保持用於SELECT語句的共用鎖。共用鎖會在數據讀取之後立即被SQL Server釋放。需要一致讀的時候這將是一個問題。我們將下麵的"獲取一致的可重覆讀操作"實現。

    現在切換到查詢視窗1並嘗試再次讀數據：

    SELECT

        FirstName, LastName, EmailAddress

FROM

        Person.Contact

WHERE

        ContactID = 1

    由於SELECT語句被阻塞，因此這個查詢並沒有結束。SQL Server會嘗試在ContactID= 1的鍵上獲取一個共用鎖，但是由於在查詢視窗2中的UPDATE語句對其有一個排他鎖，因此這個操作不可能完成。雖然查詢視窗2處於已提交讀級別(由於您沒有更改預設級別)，但排他鎖依然存在。這個阻塞將持續存在，因為數據更改的排他鎖會一直保持直到事務結束。

切換到查詢視窗2，讓查詢視窗1中的查詢繼續運行。鍵入並執行以下SELECT語句檢查資料庫中的授權和等待的鎖。

可以看一個狀態為WAIT的共用鎖。這是查詢視窗1中運行的查詢。它在等待查詢視窗2中的查詢，後者在同樣的資源上有一個排他鎖。

在查詢視窗2中執行一個ROLLBACK TRAN語句來回滾UPDATE語句。然後切換回查詢視窗1。可以看到，查詢視窗1中的查詢完成了，並且其結果與以前的一樣。查詢視窗2中的事務結束的時候，鎖被釋放了，以至查詢視窗1中的查詢不再被阻塞。由於查詢視窗2中的事務回滾，因此查詢視窗1中得到的結果是原來的數據。如果查詢視窗2中的事務被提交，則查詢視窗1中會得到新的數據作為結果。

在查詢視窗1中執行一個COMMIT TRAN語句並關閉所有的查詢視窗。

可以看出，在(預設)已提交讀級別中SQL Server會等到排他鎖釋放之後再進行讀操作，以此來獲取真正的提交數據。還可以看出，共用鎖會持續到數據被讀取之後，而排他鎖會持續到事務提交之後。在許多事務幾乎同時更改數據的時候這種行為可能會造成問題。在這些情況下，由於排他鎖造成的阻塞，讀數據會非常慢。但在有些情況下，使用最後提交的數據版本是恰當的。在這些情況下，可以將已提交讀級別更改為已提交讀快照級別。

如果要在視窗1讀取數據的話，可以使用這樣的方法：

SELECT

    FirstName, LastName, EmailAddress

FROM

    Person.Contact WITH (NOLOCK)

WHERE

    ContactID = 1

    讓它取消所有的鎖機制，那麼排他鎖也不會影響到這句查詢。

    使用NOLOCK註意：在 SQL Server 中，NOLOCK 提示將啟用"未提交讀"行為。在 SQL Server Mobile 中，使用 NOLOCK 提示仍會賦予"提交讀"隔離級別。SQL Server Mobile 將維護數據副本，以確保可以讀取數據而不需要使用共用鎖幫助保護數據。

使用已提交讀快照級別

激活已提交讀快照級別

USE master;

ALTER DATABASE AdventureWorks

SET READ_COMMITTED_SNAPSHOT ON

    註意：設置 READ_COMMITTED_SNAPSHOT 選項時，資料庫中僅允許存在執行 ALTER DATABASE 命令的連接。在 ALTER DATABASE 完成之前，資料庫中不允許有其他打開的連接。資料庫不必處於單用戶模式。

現在，執行以下代碼開始一個事務並像前面一樣更改EmailAddress(但要讓事務處於打開狀態)：

USE AdventureWorks;

BEGIN TRAN

UPDATE Person.Contact

SET EmailAddress = '[email protected]'

WHERE ContactID = 1;

打開第二個查詢視窗並執行以下語句來讀取ContactID 1的列Name和EmailAddress列。

    USE AdventureWorks;

BEGIN TRAN

SELECT FirstName, LastName, EmailAddress

FROM Person.Contact

WHERE ContactID = 1;

返回了聯繫人Gustavo Achong的EmailAddress [email protected]，這是這一行最後提交的版本。不像沒有快照的已提交讀級別那樣，這個查詢不會被阻塞。關閉查詢視窗2並切換到查詢視窗1。

執行以下語句來回滾事務並切換回已提交讀級別(這個查詢將等待直到關閉查詢視窗2)：

ROLLBACK TRAN

GO

USE master;

ALTER DATABASE AdventureWorks

SET READ_COMMITTED_SNAPSHOT OFF

重要提示 這個隔離級別可以用於減少阻塞。但要意識到這是一個資料庫選項。當它發生了更改，將在資料庫系統中使用已提交讀級別的所有事務也會改變它們的行為。因此，只有在所有這些事務讀最後提交的數據版本與讀真正提交的數據版本在邏輯上同樣正確的時候，使用這種級別才是明智的。

獲取一致的可重覆讀操作

已提交讀級別的一個缺點是，一個事務讀取的數據在事務運行期間可能被另一個事務更改。因此，在兩種已提交讀級別下，不能保證一致性讀。獲取一致性讀的意思是，在一個事務中，讀取的數據始終是一樣的。

1.  已提交讀在讀數據的時候使用共用鎖，但在讀操作完成後會立即釋放這個鎖。因此，其他事務可以更改剛被讀過的數據。

2.  已提交讀快照讀取最後一次提交的數據版本。當它第二次讀數據的時候，最後一次提交的版本可能由於第二個事務已經提交了對數據的更改而變成一個新版本。

在需要一致性讀的時候(例如對於報表)，可能這種不一致性會導致問題。想象一下，您的事務通過數據計算了一些商業數值。在已提交讀級別中進行這種計算的時候，可能由於基礎數據在事務計算過程中發生了變化而導致這些值被錯誤計算。為了成功地執行這個計算，可以使用快照隔離級別。它會使用行版本管理來提供數據的提交版本，但與已提交讀快照不同的是，它總會提供在開始事務時最後提交的數據版本。因此，SQL Server始終會在整個事務執行過程中獲取同樣的數據。

使用快照隔離級別

    快照隔離級別需要在資料庫中一次性地激活。激活之後，每個連接可以在需要的時候使用它。

    USE master;

ALTER DATABASE AdventureWorks

SET ALLOW_SNAPSHOT_ISOLATION ON;

    現在假設我們希望運行一些基於Sales.SalesOrderDetail表的報表，但需要一致性的讀操作。執行以下語句為事務激活快照隔離級別並開始一個返回訂單行合計的事務。記住OrderTotal的值。

USE AdventureWorks;

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

BEGIN TRAN

SELECT SUM(LineTotal) as OrderTotal

FROM Sales.SalesOrderDetail

WHERE SalesOrderID = 43659

參數SNAPSHOT的含義：

1.      指定事務中任何語句讀取的數據都將是在事務開始時便存在的數據的事務上一致的版本。事務只能識別在其開始之前提交的數據修改。在當前事務中執行的語句將看不到在當前事務開始以後由其他事務所做的數據修改。其效果就好像事務中的語句獲得了已提交數據的快照，因為該數據在事務開始時就存在。

2.      除非正在恢複數據庫，否則 SNAPSHOT 事務不會在讀取數據時請求鎖。讀取數據的 SNAPSHOT 事務不會阻止其他事務寫入數據。寫入數據的事務也不會阻止 SNAPSHOT 事務讀取數據。

3.      在資料庫恢復的回滾階段，如果嘗試讀取由其他正在回滾的事務鎖定的數據，則 SNAPSHOT 事務將請求一個鎖。在事務完成回滾之前，SNAPSHOT 事務會一直被阻塞。當事務取得授權之後，便會立即釋放鎖。

4.      必須將 ALLOW_SNAPSHOT_ISOLATION 資料庫選項設置為 ON，才能開始一個使用 SNAPSHOT 隔離級別的事務。如果使用 SNAPSHOT 隔離級別的事務訪問多個資料庫中的數據，則必須在每個資料庫中將 ALLOW_SNAPSHOT_ISOLATION 都設置為 ON。

5.      不能將通過其他隔離級別開始的事務設置為 SNAPSHOT 隔離級別，否則將導致事務中止。如果一個事務在 SNAPSHOT 隔離級別開始，則可以將它更改為另一個隔離級別，然後再返回 SNAPSHOT。一個事務從執行 BEGIN TRANSACTION 語句開始。

6.      在 SNAPSHOT 隔離級別下運行的事務可以查看由該事務所做的更改。例如，如果事務對錶執行 UPDATE，然後對同一個表發出 SELECT 語句，則修改後的數據將包含在結果集中。

    打開第二個查詢視窗並更新SalesOrderDetail表以更改查詢視窗1中用到的基礎數據。(如果希望重覆這個示例，將OrderQty的值5更改為其他數字以使以下代碼能真正地更改資料庫中的數據)：

    USE AdventureWorks;

UPDATE Sales.SalesOrderDetail

SET OrderQty = 5

WHERE SalesOrderID = 43659

AND ProductID = 777

    關閉查詢視窗2，切換到查詢視窗1，然後重覆下麵的SELECT語句。

    SELECT SUM(LineTotal) as OrderTotal

FROM Sales.SalesOrderDetail

WHERE SalesOrderID = 43659

    可以看出，由於快照隔離級別忽略了事務運行過程中數據的更改，因此結果與以前的相同。在快照級別下總會提供在事務開始時最後提交的值。

提交這個事務並執行以下代碼再次重覆這個查詢：現在可看到，由於事務結束了，因此結果發生了變化。

COMMIT TRAN

SELECT SUM(LineTotal) as OrderTotal

FROM Sales.SalesOrderDetail

WHERE SalesOrderID = 43659

    執行以下代碼關閉AdventureWorks資料庫的快照隔離級別：

    ALTER DATABASE AdventureWorks

SET ALLOW_SNAPSHOT_ISOLATION OFF;

避免同時發生的數據更新

如前所述，快照隔離級別並不在讀操作的時候鎖定數據，但能夠在整個事務中提供一致性的視圖。在某些情況下，有必要在整個事務的執行過程中鎖定數據以避免其他事務對數據的更改。假設希望為一個訂單開發票。首先需要獲取數據並檢查它，然後為其生成發票。在這種情況下，需要從事務起始就鎖定數據以避免其他事務更改它。在這種情況下，快照隔離或者已提交讀隔離級別都不是好的選擇。對於這種情況，可以使用可重覆讀隔離級別。這個隔離級別與沒有快照的已提交讀級別的工作過程相似，但它會保持共用鎖直至事務結束。因此，它防止了對數據的更新。

使用可重覆讀隔離級別

    假設希望處理OrderID為43659的訂單。首先，必須選擇數據。為了防止其他事務更改正在讀的數據，使用可重覆讀隔離。

    USE AdventureWorks;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

BEGIN TRAN

SELECT SalesOrderID, SalesOrderDetailID, ProductID, OrderQty

FROM Sales.SalesOrderDetail

WHERE SalesOrderID = 43659

    參數REPEATABLE READ的含義：

1.  指定語句不能讀取已由其他事務修改但尚未提交的行，並且指定，其他任何事務都不能在當前事務完成之前修改由當前事務讀取的數據。

2.  對事務中的每個語句所讀取的全部數據都設置了共用鎖，並且該共用鎖一直保持到事務完成為止。這樣可以防止其他事務修改當前事務讀取的任何行。其他事務可以插入與當前事務所發出語句的搜索條件相匹配的新行。如果當前事務隨後重試執行該語句，它會檢索新行，從而產生幻讀。由於共用鎖一直保持到事務結束，而不是在每個語句結束時釋放，所以併發級別低於預設的 READ COMMITTED 隔離級別。此選項只在必要時使用。

打開第二個查詢視窗並執行以下代碼嘗試更新SalesOrderDetail表以更改查詢視窗1中要使用的基礎數據：

    UPDATE Sales.SalesOrderDetail

SET OrderQty = 5

WHERE SalesOrderID = 43659

AND ProductID = 777

    查詢會等待。不像快照隔離級別，不可能更新數據，因為共用鎖會保持以防止其他事務更改數據。這個鎖可以通過前面用過的管理視圖sys.dm_tran_locks查看。

    單擊工具條上的"取消執行查詢"按鈕取消在查詢視窗2中的查詢。而執行以下INSERT語句在訂單中加入一個新行項。

    INSERT INTO Sales.SalesOrderDetail

(

    SalesOrderID,

    CarrierTrackingNumber,

    OrderQty,

    ProductID,

    SpecialOfferID,

    UnitPrice,

    UnitPriceDiscount

)

VALUES(43659,'4911-403C-98',1,758,1,874,0)

    註意，即使正處於可重覆讀隔離級別，這個語句也會成功執行。因為可重覆讀會鎖定數據以阻止數據的更新，但INSERT語句向資料庫中插入新數據，這是允許的。新行處於查詢視窗1中事務SELECT語句的查詢範圍之中，所以會在事務下一次獲取相同數據的時候被讀取到。這稱作幻像讀。

    重覆SELECT語句並提交這個事務，如下所示：

    SELECT SalesOrderID, SalesOrderDetailID, ProductID, OrderQty

FROM Sales.SalesOrderDetail

WHERE SalesOrderID = 43659

COMMIT TRAN

    可以觀察到，新行被SELECT語句讀取了，因為它處於這個語句的查詢範圍之內。可重覆讀級別會阻止現有數據被更改，但不會阻止新數據插入SELECT語句的查詢範圍內。

其他

    SET TRANSACTION一共有以下幾種級別：

    SET TRANSACTION ISOLATION LEVEL

{ READ UNCOMMITTED

| READ COMMITTED

| REPEATABLE READ

| SNAPSHOT

| SERIALIZABLE

}

[ ; ]

    上面的例子中沒有提到的幾種隔離級別的說明：

1. READ UNCOMMITTED

指定語句可以讀取已由其他事務修改但尚未提交的行。

在 READ UNCOMMITTED 級別運行的事務，不會發出共用鎖來防止其他事務修改當前事務讀取的數據。READ UNCOMMITTED 事務也不會被排他鎖阻塞，排他鎖會禁止當前事務讀取其他事務已修改但尚未提交的行。設置此選項之後，可以讀取未提交的修改，這種讀取稱為臟讀。在事務結束之前，可以更改數據中的值，行也可以出現在數據集中或從數據集中消失。該選項的作用與在事務內所有 SELECT 語句中的所有表上設置 NOLOCK 相同。這是隔離級別中限制最少的級別。

在 SQL Server 2005 中，您還可以使用下列任意一種方法，在保護事務不臟讀未提交的數據修改的同時儘量減少鎖定爭用：

1.  READ COMMITTED 隔離級別，並將 READ_COMMITTED_SNAPSHOT 資料庫選項設置為 ON。

2.  SNAPSHOT 隔離級別。

1. READ COMMITTED

指定語句不能讀取已由其他事務修改但尚未提交的數據。這樣可以避免臟讀。其他事務可以在當前事務的各個語句之間更改數據，從而產生不可重覆讀取和幻像數據。該選項是 SQL Server 的預設設置。

READ COMMITTED 的行為取決於 READ_COMMITTED_SNAPSHOT 資料庫選項的設置：

1.  如果將 READ_COMMITTED_SNAPSHOT 設置為 OFF（預設設置），則資料庫引擎 會使用共用鎖防止其他事務在當前事務執行讀取操作期間修改行。共用鎖還會阻止語句在其他事務完成之前讀取由這些事務修改的行。語句完成後便會釋放共用鎖。

2.  如果將 READ_COMMITTED_SNAPSHOT 設置為 ON，則資料庫引擎 會使用行版本控製為每個語句提供一個在事務上一致的數據快照，因為該數據在語句開始時就存在。不使用鎖來防止其他事務更新數據。

當 READ_COMMITTED_SNAPSHOT 資料庫選項設置為 ON 時，您可以使用 READCOMMITTEDLOCK 表提示為 READ_COMMITTED 隔離級別上運行的事務中的各語句請求共用鎖，而不是行版本控制。

    註意：設置 READ_COMMITTED_SNAPSHOT 選項時，資料庫中僅允許存在執行 ALTER DATABASE 命令的連接。在 ALTER DATABASE 完成之前，資料庫中不允許有其他打開的連接。資料庫不必處於單用戶模式。

1. SERIALIZABLE

請指定下列內容：

1.  語句不能讀取已由其他事務修改但尚未提交的數據。

2.  任何其他事務都不能在當前事務完成之前修改由當前事務讀取的數據。

3.  在當前事務完成之前，其他事務不能使用當前事務中任何語句讀取的鍵值插入新行。

範圍鎖處於與事務中執行的每個語句的搜索條件相匹配的鍵值範圍之內。這樣可以阻止其他事務更新或插入任何行，從而限定當前事務所執行的任何語句。這意味著如果再次執行事務中的任何語句，則這些語句便會讀取同一組行。在事務完成之前將一直保持範圍鎖。這是限制最多的隔離級別，因為它鎖定了鍵的整個範圍，併在事務完成之前一直保持範圍鎖。因為併發級別較低，所以應只在必要時才使用該選項。該選項的作用與在事務內所有 SELECT 語句中的所有表上設置 HOLDLOCK相同。

需要註意的地方：

1.  一次只能設置一個隔離級別選項，而且設置的選項將一直對那個連接始終有效，直到顯式更改該選項為止。事務中執行的所有讀取操作都會在指定的隔離級別的規則下運行，除非語句的 FROM 子句中的表提示為表指定了其他鎖定行為或版本控制行為。

2.  事務隔離級別定義了可為讀取操作獲取的鎖類型。針對 READ COMMITTED 或 REPEATABLE READ 獲取的共用鎖通常為行鎖，儘管當讀取引用了頁或表中大量的行時，行鎖可以升級為頁鎖或表鎖。如果某行在被讀取之後由事務進行了修改，則該事務會獲取一個用於保護該行的排他鎖，並且該排他鎖在事務完成之前將一直保持。例如，如果 REPEATABLE READ 事務具有用於某行的共用鎖，並且該事務隨後修改了該行，則共用行鎖便會轉換為排他行鎖。

3.  在事務進行期間，可以隨時將事務從一個隔離級別切換到另一個隔離級別，但有一種情況例外。即在從任一隔離級別更改到 SNAPSHOT 隔離時，不能進行上述操作。否則會導致事務失敗並回滾。但是，可以將在 SNAPSHOT 隔離中啟動的事務更改為任何其他隔離級別。

4.  將事務從一個隔離級別更改為另一個隔離級別之後，便會根據新級別的規則對更改後讀取的資源執行保護。在更改前讀取的資源將繼續按照以前級別的規則受到保護。例如，如果某個事務從 READ COMMITTED 更改為 SERIALIZABLE，則在該事務結束前，更改後所獲取的共用鎖將一直處於保留狀態。