一直以為很了解sqlserver的加鎖程序，在分析一些特殊情況下的死鎖之后，尤其是并發單表操作發生的死鎖，對于加解鎖的程序，有了一些重新的認識，之前的知識還是有一些盲區在里面的，
delete加鎖與解鎖步驟是怎么樣的？什么時候對那些物件，加什么型別的瑣，加鎖與索引的關系是怎么樣的，什么時候釋放鎖？整個程序鎖是如何參與整個delete操作程序表的？
這里通過一個非常簡單的delete陳述句，來分析一條delete執行程序中加解鎖的程序，
測驗表創建
用一個最最簡單的例子做了跟蹤，對鎖的申請和釋放，有了更清晰的認識，這個程序非常有意思，看完之后會非常清晰地認識到delete陳述句執行程序中加解鎖的步驟是怎么樣的，
如果對一個SQL加解鎖的步驟不清楚，解決死鎖，只能說經驗，或者說是靠蒙、亦或靠優化SQL地去減少死鎖的可能性（天下武功，唯快不破），
如下腳本，創建測驗表，待用，
跟蹤的測驗洗掉sql陳述句為：delete from test_require_release_lock where col2 = 'a999' and col3 = 'b999'，where條件的目標資料是1行，條件是用到where的第一個篩選條件的索引，
測驗資料的基本資訊
先拿到一些基本的資訊物件id，索引Id，key值等物理Id（RowHashId）等等，這些Id稍后會清晰地展示在profile跟蹤日志中，能幫助我們去了解到底在什么物件（資料行，索引行）加什么型別的鎖，
當前值得物理地址（RowHashId）
Profile跟蹤日志
如下是profile跟蹤出來的delete from test_require_release_lock where col2 = 'a999' and col3 = 'b999'陳述句執行程序中表級別鎖的申請和釋放
我只能說：這個case包括資料，是反復測驗各種情況之后，最最簡單的一種情況了，稍微復雜一點的情況，對于一行資料的洗掉，加解鎖的程序至少要兩屏才能顯示出來，
加解鎖程序分析
這個程序可以大致分為3個階段，僅僅執行一條資料洗掉的delete陳述句，就有37步之多，為了簡化這個程序，這里只看洗掉程序中，資料/索引行上的加解鎖資訊，如圖所示的前23步，
階段1:根據where條件查找資料的物理Id，也即RID，這個程序是IU/U鎖，雖然執行的是delete，此程序不刪任何資料，只是根據條件，找到資料的RID
階段2：依次洗掉資料行和索引行，也即依次洗掉RID，主鍵索引，多個索引鍵索引，這個程序涉及到第一步的IU/U鎖轉換IX/X以及新申請IX/X鎖
階段3：（洗掉完成）依次釋放之前步驟申請尚未釋放的鎖
如下是profile中這個程序中每一步的說明
階段1：
1，申請基表82099333上意向IX鎖
2，申請目標行索引欄位col2(fe51867f3259)所在page的IU鎖
3，申請目標行索引欄位col2(fe51867f3259)Key級別的U鎖
4，申請目標所索引欄位col2(fe51867f3259)對應的RID所在page的IU鎖
5，申請目標所索引欄位col2(fe51867f3259)對應的RID行的RID的U鎖
階段2
6，升級4申請的IU鎖成IX鎖
7，升級5申請的U鎖成X鎖 ***洗掉RID行，也即資料行
8，申請6（已經申請到的）RID對應的主鍵索引(9606db9499cf)所在page的IX鎖
9，申請主鍵索引的key級別的X鎖(9606db9499cf)，***洗掉主鍵行
10，釋放9申請的鎖
11，釋放8申請的鎖
12，申請目標行索引欄位col2 (fe51867f3259)所在page的IX鎖
13，申請目標行索引欄位col2(fe51867f3259)Key級別的X鎖，***洗掉col2上的索引行
14，釋放13申請的鎖
15，釋放12申請的鎖
16，申請目標行索引欄位(fe51867f3259)對應的Col3欄位(aa0cc0efc6d9)索引所在page的IX鎖
17，申請目標行索引欄位(fe51867f3259)對應的Col3欄位(aa0cc0efc6d9)索引Key級別的X鎖，***洗掉col3上的索引行
階段3
18，釋放16申請的鎖
19，釋放17申請的鎖
20，釋放6申請的鎖
21，釋放7申請的鎖
22，釋放4申請的鎖
23，釋放5申請的鎖
24~37 釋放其它鎖
從中可以看到，鎖的申請的簡化程序是，或者其規律是：
1，根據查詢條件，依次申請查詢欄位所在Page以及欄位key本身的IU/U鎖，因為這個階段是找資料（找到加IU/U），而不是直接上來就刪資料，所以是IU/U鎖
2，根據nocluster index 找到RID，從IU/U升級RID鎖稱IX/X，進行資料行的洗掉
3，依次洗掉主鍵索引，col2上的索引，col3上的索引，進行索引行的洗掉
4，依次釋放加鎖資訊，此程序于加鎖相反（先page再Key），依次釋放KEY/RID和Page上的鎖（先key再Page）
如果是聚集索引表，會用聚集索引Key提到RID，省略RID這一步的鎖操作，
從這里可以看到，沒有聚集索引的表，主鍵索引跟普通的非聚集索引并無二致，最侄訓是要使用RID來定位資料，
這里還能夠得到另外一個結論：因為這里的主鍵索引是nonclustered的，因此該表還是資料堆表，既然是堆表，定位資料的還是RID，因此多了依次RID的鎖維護動作
以上跟蹤了一個最簡單的delete執行程序中的加鎖的步驟，其實情況可以更復雜：
1如果where條件用不到索引，
2如果where條件之一篩選出來的多行，繼續用另外的條件篩選，
3如果使用聚集索引篩選，
4如果where條件篩選后仍舊有多行資料
5如果where條件無法命中任何一行
6如果采用多個非聚集索引篩選后merge結果
稍微復雜一點的情況，涉及到的鎖都呈指數級增加，原本我以為很清楚sqlserver在執行delete操作的加鎖程序，其實還有很多細節，沒有注意到，
加解鎖是一個復雜的程序，即便是單表，也會涉及不同的索引以及資料行，為此并不難理解，為什么對于單表，除了where條件不一致，為什么會出現死鎖的原因，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/39261.html
標籤：SQL Server