前段時間在msdn的論壇上看到鄒老大對一個問題的回覆，覺得對鎖更瞭解了，先二話不說“拿來”記錄學習下。

原帖地址：http://social.msdn.microsoft.com/Forums/zh-CN/6559504d-c546-45a6-89e2-eeb75041b3e7/-?forum=sqlserverzhchs

首先是環境指令碼

CREATE TABLE [dbo].[table1](

 [A] [nvarchar](10) NULL,

 [B] [nvarchar](10) NOT NULL,

 [C] [nvarchar](10) NULL

) ON [PRIMARY]

GO

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa1', N'b1', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa2', N'b3', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b4', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b5', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b2', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b6', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b7', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa3', N'b8', N'11')

INSERT [dbo].[table1] ([A], [B], [C]) VALUES (N'aa1', N'b9', N'11')

然後是三個指令碼

--查詢1

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

 begin tran

    print convert(nvarchar(30),convert(datetime,getdate(),121),121)

       update table1

     set A='aa1'

     where B='b3'

    print convert(nvarchar(30),convert(datetime,getdate(),121),121)

    EXEC sp_lock @@spid

   waitfor  delay '00:00:10'

   update table1

     set A='aa2'

     where B='b8'

     EXEC sp_lock @@spid

    print convert(nvarchar(30),convert(datetime,getdate(),121),121)

 commit tran

--查詢二

SET TRANSACTION ISOLATION LEVEL Read UNCOMMITTED

    begin tran

  update table1

    set A='aa3'

    where B='b7'

    EXEC sp_lock @@spid

   commit tran

--查詢三：

SET TRANSACTION ISOLATION LEVEL Read UNCOMMITTED

    begin tran

  update table1

    set A='aa3'

    where B='b1'

    EXEC sp_lock @@spid

   commit tran

執行的情況是在兩個執行緒中

情況1：

先執行查詢1，然後立刻在另外一個執行緒中執行查詢2。

結果是兩邊順利的完成更新

情況2：

先執行查詢1，然後立刻在另外一個執行緒中執行查詢3.

結果是查詢3出現死鎖情況。

以上是現象

---------------------------------------------------------------------------------------------

下面我們來分析為什麼會有這個現象，首先我們先來看看update動作到底會做哪些事.

我們先開啟profiler，監控lock:acquired以及lock:released兩個專案，並且限制suid為我們需要監控的程序ID，然後我們得到下面的監控結果

我們可以得出這樣一個結論：

Update過程中對錶進行掃描依此對每行記錄下U鎖，若滿足條件則轉換為X鎖更新，若不滿足條件則釋放U鎖。由此結論，我們就可以推斷出上面分別導致死鎖，和不會導致死鎖的情況是怎樣的原因了。

情況1：

查詢1：對錶進行掃描依此對每行記錄下U鎖，若滿足條件則轉換為X鎖更新，若不滿足條件則釋放U鎖。更新完成後，若未提交則X鎖繼續保留。

注意：這裡被保留的X鎖的行數為第2行（b3），因為這個是一個堆表，排列順序一般是按照插入順序，update掃描該表時候從從第一開始掃描的

查詢2：對錶進行掃描一次對每行記錄下U鎖，因為需要查詢的目標在查詢1的X鎖之後，未能查詢到需要更新得條件既被髮生無法新增U鎖等待，這樣只有當查詢1完成查詢後，查詢2才能繼續，所以不會導致死鎖。

注意：正因為查詢2要滿足X鎖的條件在第7行以(b7),所以當查詢2的U鎖獲取再釋放動作，到了第二行的時候，遇到查詢1保留的X鎖，整個事務進入等待狀態，並且未留下任何可以干擾查詢1的第二個語句的鎖，所以，當查詢1直接完畢後，查詢2得以繼續正常執行完成

情況2：

查詢1：對錶進行掃描依此對每行記錄下U鎖，若滿足條件則轉換為X鎖更新，若不滿足條件則釋放U鎖。更新完成後，若未提交則X鎖繼續保留。

查詢3：對錶進行掃描依此對每行記錄下U鎖，因為需要update的條件在查詢1前就被發現並加上X鎖，但是掃描到查詢1鎖新增的X鎖後無法新增U鎖導致需要等待查詢1完成後才能繼續提交。這時查詢1的第二個update語句開始執行，更新U鎖時，發現查詢2的X，要等待查詢3的X鎖釋放同時達成死鎖條件。

注意：正因為查詢3的新增X鎖動作，在第一行就發生了（b1），然後達到第二行是，又被查詢1保留的X鎖阻止了繼續操作第二行(b3)。這樣他就需要等待查詢1釋放在第二行的X鎖才能繼續update，但是查詢1的第二個語句，又需要查詢3先釋放在第一行(b1)的X鎖，就這樣形成了死鎖條件。

如此這個在 同一頁面，不同的行的互相死鎖，和不死鎖的原因就相當清楚了。

這個案例重點就是，update是一個兩個動作的事務，分為查詢和修改，並且修改這個動作是通過對各個滿足條件的行做X鎖來保證一致性的

而這個動作當遇到併發的時候，即使是不同的行也可能導致互相死鎖。

通過這個案例我們應該得出一個結論，就是應該避免對一個表的多執行緒操作。因為他們很可能造成死鎖。

--------------------------------------------------------------------------------------------

以下是延伸研究：

        那麼現在又一個問題，若update動作會對整個表進行掃描，並一一進行U鎖獲取釋放動作，這必然會造成大量效能消耗，

是否大資料的的情況會不同呢？增加索引是否會改善呢？增加主鍵是否會改善呢？

我們進行以下實驗

1、不增加主鍵或索引，僅對錶擴大資料量，然後update其中第1000行記錄

--環境建立語句
Create Table dbo.a2
(
id int identity(1,1),
value1 char(10),
value2 varchar(20)
)

declare @n int
set @n=1
--測試資料填充
while (@n<10000)
begin
INSERT INTO dbo.a2
           (value1       ,value2
           )
     VALUES
           (REPLICATE('c',10)
           ,CONVERT(varchar(20),REPLICATE('F',20))
           )
set @[email protected]+1
end

產生的鎖和釋放數量和行數*2差距不大，這讓我們直接確認了表掃描的可怕

2、增加主鍵,並擴大資料量

    建立一個表，int列為自增主鍵，插入1W筆資料，使用主鍵update其中第1000行記錄

這次我們可以看到整個事務中根本不使用U鎖了，而是先通過S鎖，定位到具體頁面，再直接鎖定對應行，實現更新。

3、不新增主鍵，而是查詢表新增索引，資料量10000

Create Table dbo.a3
(
id int identity(1,1),
value1 char(10),
value2 varchar(20)
)
create index ix_a3 on a3 (id)

declare @n int
set @n=1

while (@n<10000)
begin
INSERT INTO dbo.a3
           (value1       ,value2
           )
     VALUES
           (REPLICATE('c',10)
           ,CONVERT(varchar(20),REPLICATE('F',20))
           )
set @[email protected]+1
end

其中1:18051是索引頁，

這個查詢結果行數大約80行，這個是輸出結果的末尾，上面反覆出現S鎖的釋放。

我們可以判斷這個是通過查詢索引，定位到 索引對應行以後， 再對對應資料行進行U鎖新增釋放動作。注意你可以看到這裡有一個對索引頁的IU動作，這裡是在確定是否該更改會影響到索引頁，因為沒有使索引頁發生更變，從而釋放了這個IU鎖。