SQL Server死鎖診斷--同一行數據在不一樣索引操做下引發的死鎖

 

 

死鎖概述

對於數據庫中出現的死鎖，通俗地解釋就是：不一樣Session（會話）持有一部分資源，而且同時相互排他性地申請對方持有的資源，而後雙方都得不到本身想要的資源，從而形成的一種僵持的現象。
固然，在任何一種數據庫中，這種僵持的狀況不會一直持續下去，由於一直持續下去雙方永遠都沒法執行，沒有任何意義，
在SQL Server中，後臺線程會以3秒鐘一次的頻率檢測死鎖Session，而且選擇其中一個回滾代價相對較低的做爲犧牲品，從而使解除不一樣Session相互僵持的現象。
所以SQL Server中死鎖的僵持時間不會超過3秒鐘。

一般狀況下，最簡單也是最多見的死鎖是發生在不一樣表級別的，
Session 1 第一步修改A表，第二步修改B表，
Session 2第一步修改B表，第二步修改A表，
當發生Session 1與Session 2推動順序發生交叉的時候，死鎖就發生了，這種結局辦法也比較簡單，以相同的推動順序進行操做便可解除死鎖。

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

 

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

不過死鎖的種類有不少種，上述的僅是一種最簡單最多見的一種死鎖，
理論上，只要知足死鎖發生的條件：不一樣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())）
可能須要執行幾回嘗試，就會觀察到其中一個SQLQueryStress中發生了異常信息

打開其異常信息的詳細內容 ，會發現是死鎖

 

首先查一下表上索引的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鎖
結果：死鎖！

 

關於waitresource的解讀，參考：https://blog.csdn.net/kk185800961/article/details/41687209

 

兩個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，嘗試改變隔離級別，嘗試序列化隔離級別。

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

參考：
http://www.javashuo.com/article/p-shdwsrpu-kd.html
https://blogs.msdn.microsoft.com/apgcdsd/2012/02/27/sql-serverdeadlock/
https://www.simple-talk.com/sql/performance/sql-server-deadlocks-by-example/

 

 

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