利用索引下降併發事務引發的鎖【轉】

時常，來自不一樣鏈接的線程會對同一張表進行讀/更新操做，這種併發操做會致使阻塞，同時SQL Server會自動處理以防止髒讀。然而，有種情景很常見，那就是每一個鏈接要讀/更新的行互相排斥，換句話說，就是各個鏈接讀/更新的行沒有交集。在這片文章中，將像你們展現如何恰當地使用索引來下降阻塞的發生，以便多個讀/更新可以同時操做同一張表。

建立TEST表以下：

1. SET ANSI_NULLS ON
2. GO  
4. SET QUOTED_IDENTIFIER ON
5. GO  
7. CREATE TABLE [dbo].[TEST](  
8.     [ID] [int] IDENTITY(1,1) NOT NULL,  
9.     [NAME] [nvarchar](20) NULL,  
10.     [TEL] [varchar](20) NULL
11. ) ON [PRIMARY]  
13. GO 

塞入兩筆記錄：

1. INSERT TEST(NAME,TEL)  
2. SELECT N'阿三','12345678901'
3. UNION ALL
4. SELECT N'李四','23456789012'

開啓兩個查詢，分別執行以下T-SQL：

1. BEGIN TRAN  
2. UPDATE TEST  WITH(ROWLOCK)  
3. SET TEL = '11111111111'
4. WHERE ID=1 

1. BEGIN TRAN  
2. UPDATE TEST  WITH(ROWLOCK)  
3. SET TEL = '22222222222'
4. WHERE ID=2 

這是咱們能夠發現第一個T-SQL執行後的情況以下：

 

然而，第二個T-SQL執行時就pending在那裏：

經過sp_lock查看：

由上圖能夠看出，資源1:498424:0被spid（56）排他鎖定（X），而迫使spid（52）對其更新（U）等待（WAIT），所以就是咱們看到的執行第二個更新事務時，一直處於等待狀態，由於排他鎖（X）沒有釋放。 

關於鎖模式的說明以下，更多信息可參考官網（http://technet.microsoft.com/zh-cn/library/ms175519.aspx）。

鎖模式

說明

共享 (S)
用於不更改或不更新數據的讀取操做，如 SELECT 語句。

更新 (U)
用於可更新的資源中。 防止當多個會話在讀取、鎖定以及隨後可能進行的資源更新時發生常見形式的死鎖。

排他 (X)
用於數據修改操做，例如 INSERT、UPDATE 或 DELETE。 確保不會同時對同一資源進行多重更新。

意向
用於創建鎖的層次結構。 意向鎖包含三種類型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。

架構
在執行依賴於表架構的操做時使用。 架構鎖包含兩種類型：架構修改 (Sch-M) 和架構穩定性 (Sch-S)。

大容量更新 (BU)
在向表進行大容量數據複製且指定了 TABLOCK 提示時使用。

鍵範圍
當使用可序列化事務隔離級別時保護查詢讀取的行的範圍。 確保再次運行查詢時其餘事務沒法插入符合可序列化事務的查詢的行。

關於鎖定資源的說明以下，更多信息可參考（http://technet.microsoft.com/zh-cn/library/ms189849(v=SQL.105).aspx）

資源

說明

RID
用於鎖定堆中的單個行的行標識符。

KEY
索引中用於保護可序列化事務中的鍵範圍的行鎖。

PAGE
數據庫中的 8 KB 頁，例如數據頁或索引頁。

EXTENT
一組連續的八頁，例如數據頁或索引頁。

HoBT
堆或 B 樹。 用於保護沒有彙集索引的表中的 B 樹（索引）或堆數據頁的鎖。

TABLE
包括全部數據和索引的整個表。

FILE
數據庫文件。

APPLICATION
應用程序專用的資源。

METADATA
元數據鎖。

ALLOCATION_UNIT
分配單元。

DATABASE
整個數據庫。

對於這種這種併發操做，咱們能夠經過索引來改善鎖：

以下建立主鍵索引：

view plain

1. ALTER TABLE [dbo].[TEST] ADD CONSTRAINT [PK_TEST] PRIMARY KEY CLUSTERED  
2. (  
3.       [ID] ASC
4. )WITH (PAD_INDEX = OFF,STATISTICS_NORECOMPUTE  =OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  =ON,ALLOW_PAGE_LOCKS  =ON)ON [PRIMARY]  
5. GO 

這時咱們再來執行兩個更新事務時，咱們發現，均能執行成功，並有沒有出現更新（U）等待（WAIT）的的狀況。 

執行第一個：

執行第二個：

查看sp_lock，在Type這一欄，並無出現RID，而出現了KEY，而且KEY的資源不同，排他鎖的狀態都是GRANT，基本互不影響。

從上面的演示說明能夠看出，正確的索引設置有助於下降併發事務引發的鎖。