本例中使用begin tran和with (holdlock)提示來觀察SQL Server在select語句中的鎖。 開啟事務是為了保證時間極短的查詢也能觀察到鎖情況,因為holdlock會在事務結束後釋放鎖。 update語句: 其上鎖情況為: 可以看到加鎖情況如下: 1.添加了表級IX鎖 2. ...
本例中使用begin tran和with (holdlock)提示來觀察SQL Server在select語句中的鎖。 開啟事務是為了保證時間極短的查詢也能觀察到鎖情況,因為holdlock會在事務結束後釋放鎖。 update語句: 其上鎖情況為: 可以看到加鎖情況如下: 1.添加了表級IX鎖 2.針對數據頁3105添加了IX鎖,以便更新其中數據行 3.對數據頁3105中對應的數據行添加了X模式的KEY鎖 4.更新完數據後要更新包含ClinicID列的相關索引,我們先看一下涉及到這個列的索引有哪些:(可以看到確實是60號索引)
select * from sys.indexes where object_id=OBJECT_ID('RIS_REQUEST')
對索引頁50160、1458239添加了IX鎖,以便更新其中索引行
5.對以上2個索引頁內的索引行添加X模式KEY鎖,更新索引行完成。
這裡有個疑問:我是按主鍵進行更新的,這意味著只涉及到一個數據行,索引也應該只有一行對應才對,為何會導致2個索引記錄的X模式KEY鎖出現?
只能去看50160、1458239這兩個頁的具體內容了,這裡我把兩個頁的具體內容全部用dbcc page轉儲出來:
50160頁只截取了可能包含主鍵2012121218060024的部分:
1458239頁總共只有這麼多行的記錄:
可以看到主鍵值為2012121218060024的索引就是在1458239索引頁的第2行,其對應的hash值也是sp_lock中看到的7be5a319785d,而另一個hash值fcee1248c8e6對應的索引行則沒有找到,這可以預見,因為ClinicID被更新後其HASH值必定發生變化。