死鎖概述

對於資料庫中出現的死鎖，通俗地解釋就是：不同Session（會話）持有一部分資源，並且同時相互排他性地申請對方持有的資源，然後雙方都得不到自己想要的資源，從而造成的一種僵持的現象。
當然，在任何一種資料庫中，這種僵持的情況不會一直持續下去，因為一直持續下去雙方永遠都無法執行，沒有任何意義，
在SQL Server中，後臺執行緒會以3秒鐘一次的頻率檢測死鎖Session，並且選擇其中一個回滾代價相對較低的作為犧牲品，從而使解除不同Session相互僵持的現象。
因此SQL Server中死鎖的僵持時間不會超過3秒鐘。

通常情況下，最簡單也是最常見的死鎖是發生在不同表級別的，
Session 1 第一步修改A表，第二步修改B表，

以下演示一種不用於以上情況，稍微特殊一點的死鎖。

同一張表上發生的死鎖演示

不過死鎖的種類有很多種，上述的僅是一種最簡單最常見的一種死鎖，
理論上，只要滿足死鎖發生的條件：不同Session（會話）排他性地持有一部分資源，並且相互申請對方持有的資源
都會產生死鎖，並不僅僅是在不同的表上，而是在不同的資源上，這種資源，可以是同一張表，甚至同一行資料上，以下舉例說明。

--TestDeadLock的Id是主鍵（預設生成聚集索引），Col2欄位是唯一性的非聚集索引
 

create table TestDeadLock
(
    Id int constraint pk_TestDeadLock_id primary key,
    Col2 int constraint uk_TestDeadLock_col2 unique,
    Remark varchar(100)
)

然後利用SQLQueryStress，開啟兩個回話，分別按照聚集索引和非聚集索引，刪除同一行資料（造測試資料的時候會設定Id和Col2都為1），
如下圖所示
一開始先讓這兩個Session一直執行（空執行），隨後往TestDeadLock表中插入一行資料（insert into [TestDeadLock] values (1,1,newid())）

開啟其異常資訊的詳細內容 ，會發現是死鎖

首先查一下表上索引的id，一下分析加鎖的過程中會用到。
pk_TestDeadLock_id 是聚集索引，其Id是 72057594050314240
uk_TestDeadLock_col2 是非聚集索引，其Id是 72057594050379776

利用sqlserver自帶的system_health擴充套件事件，觀察其死鎖資訊（xml_deadlock_report）

SELECT  CAST(xet.target_data AS XML)
FROM    sys.dm_xe_session_targets xet
        JOIN sys.dm_xe_sessions xe ON ( xe.address = xet.event_session_address )
WHERE   xe.name = 'system_health'

select xml_event_data,
xml_event_data.value('(event[@name="xml_deadlock_report"]/@timestamp)[1]','datetime') Execution_Time,
xml_event_data.value('(event/data/value)[1]','varchar(max)') Query
from 
(
    SELECT event_table.xml_event_data
    FROM(
            SELECT CAST(event_data AS XML) xml_event_data 
            FROM sys.fn_xe_file_target_read_file(N'your path \system_health_*', NULL, NULL, NULL)
        ) AS event_table
        CROSS APPLY xml_event_data.nodes('//event') n (event_xml)
    WHERE  event_xml.value('(./@name)', 'varchar(1000)') IN ('xml_deadlock_report')   
) v 
order by Execution_Time

得到如下的死鎖資訊，擴充套件事件中的xml_deadlock_report清楚吧地表明：對於當前這一行資料（8194443284a0一樣）
delete from [TestDeadLock] where Id= 1 　　　　等待非聚集索引上的鎖（waitresource="KEY: 11:72057594050379776 (8194443284a0)" ）
delete from [TestDeadLock] where Col2 = 1　 　  等待聚集索引上的鎖（waitresource="KEY: 11:72057594050314240 (8194443284a0)" ）
兩者有死鎖，肯定是相互等待對方已經持有的資源（索引上的鎖）
因此，當前這個死鎖可以這麼理解
delete from [TestDeadLock] where Id=1 　　　　持有聚集索引上的U鎖，申請非聚集索引上的X鎖
delete from [TestDeadLock] where Col2 = 1 　　 持有非聚集索引上的X鎖，申請聚集索引上的U鎖
結果：死鎖！

兩個SQL對同一行資料的加鎖順序分析

上述分析只是根據已有現象推測其過程，如果能夠觀察到每一個sql語句執行過程中的鎖的申請與釋放順序，問題就更容易理解了。
以下利用profile觀察兩個語句執行過程中對鎖的申請和釋放順序

觀察一下delete from [TestDeadLock] where Id = 1 這句sql的執行過程的鎖的申請順序
profile裡就很清楚，對於delete from [TestDeadLock] where Id = 1
先申請聚集索引（72057594050314240）page層面上的意向排它鎖（IX），轉為行級別的排它鎖（X），再申請非聚集索引（72057594050379776）的page層面意向排它鎖（IX），轉換為行級別排它鎖（X）

對於delete from [TestDeadLock] where Col2 = 1
先申請非聚集索引（72057594050379776）上page層面的意向更新鎖（IU），轉為行級別更新鎖鎖（U），再申請page層面聚集索引（72057594050314240）的意向排它鎖（IX），轉換為行級別排它鎖（X）

通過以上加鎖順序的分析，印證了上述加鎖方式的推測，不難理解兩個SQL語句為什麼會發生死鎖。
仍然回到死鎖的概念上：不同Session（會話）排他性地持有一部分資源，並且同時申請對方持有的資源
這種相互持有的資源，可以是不同表上的資源，可以是同一個表上的資源，甚至可以是同一行資料的不同資源（不同索引的資源）
只要發生不同Session相互排他性地持有對方想要的資源，死鎖就會發生。

這種方式是雙方根據不同的索引同時delete引起的死鎖，類似上述情況，可以延伸到雙方同時update，雙方同時delete或者update，雙方同時update或者select等等
只要是索引推進順序不一致，都有可能引起死鎖的發生，此類問題可以歸結為同一行資料上，不同索引操作引起的死鎖。

如何解決？

對於常見的不同表上的推進順序不當造成的死鎖，只要改進持鎖的順序即可，也就是按照同一種方式來操作不同表中的資料。
對於上述的問題，不是不同表上的推進順序造成的，而是同一張表的同一行資料的資源推進順序不當導致的，在sql語句層面看起來並沒有什麼不妥當的，因此只能從鎖的範圍或者隔離級別上進行調整。
1，嘗試從業務入手，是否能夠按照統一的方式對資料進行操作。
2，使用佇列消除併發操作的峰值。
3，嘗試tablockx，一次性鎖定整個表。
4，嘗試改變隔離級別，嘗試序列化隔離級別。

最後佛系一下：
很多問題都喜歡用奇怪解釋，其實很多問題並不奇怪，只是不知道而已，
技術上的問題，不知道也沒什麼大不了，知道了更沒什麼大不了，知道也僅僅是知道而已，不知道經歷一次就知道了，知不知道都沒有任何值得自豪或者自卑的
你的知識死角不能否定你的技術能力，應用層面的東西，只不過是在人家制定好的規則上玩遊戲而已，誰也不要裝。

需要注意的是：擴充套件事件中記錄的事件發生的時間，都是標準時間（格林威治時間），而其errorlog中或者自定義異常中的時間，都是當前時間