題外話：之所以寫這個部落格，是應了群裡大家的要求，從來沒有寫過，寫的不好多擔待。
引言：不要以為看到引言就覺得像是寫書，其實我是想在這裡說下我尋找死鎖的旅程。我們公司做的是web專案，大概一年前開始接手目前負責的部分就斷斷續續的出現死鎖，出現的機率不多，就像大姨媽，基本每個月都會來一次，偶爾還會兩次。開始時，只是知道程式報死鎖錯誤，但是根本無從下手，以前沒有接觸過死鎖啊，完全蒙圈啊。所以就把問題歸結為“高併發”引起的，屬於偶發問題，忽略吧！就這樣忽悠了一段時間。可以後來還是會持續的出現死鎖問題，這可怎麼辦啊。不能不管了，第一時間想到的就是百度。關於死鎖問題的帖子案例什麼的幾乎看了個遍，明白了死鎖的產生機制：資源競爭。這詞說的很到位啊，就是互相搶啊，互相傷害，就死了。開始以為是SQL語句寫的有問題，但是研究來研究去，最後確定SQL沒有問題啊。程式中的select的部分都已經加了with（nolock）了，update怎麼會死鎖呢？還給我犧牲掉了。又成了無頭命案了。有半年時間了，開始懷疑是觸發器有問題，然後各種優化表中的觸發器，然後對大家說，這回肯定好了，不會有問題了。可是沒多久，死鎖還是不約而至的出現了。好吧，我認了，為了讓程式出現死鎖後，仍然可以正常執行，加了回滾機制，就是在update時，try一下，如果執行update報錯，那麼我就把之前執行的update資料全部再修改回原來的（業務需求，特殊原因這樣寫的），就這樣，堅持了半年吧。可是沒有解決死鎖的問題，死鎖還是會時不時的出來，蒼天啊，誰來拯救我啊。期間我像各界朋友，群裡的朋友請教，都沒有得到解決。忽然有一天，無意中發現了sqlserver一項特殊的功能。加日誌標記，加跟蹤。本地測試很有效果啊，可以查到死鎖資訊，可是BOSS不讓用啊。說是影響效能。好吧，我無言以對。再後來，就這樣一直帶帶拉拉的研究死鎖，無意中又發現新的功能，可以獲取死鎖資訊，很快捷，不需要什麼特殊設定，不影響效能。堪稱是完美的查詢死鎖資訊的途徑。

說了這麼多廢話，接下來進入正題，內容並不多。查詢死鎖資訊的方式有很多，不限於此。

注意：在出現死鎖犧牲品時，可以用此方法查詢死鎖資訊，死鎖資訊寫入偶爾會略有延遲，大概1分鐘左右（沒弄清楚，不影響使用，所以剛出現死鎖，馬上查可能查不到死鎖資訊，等一會再查就有了），因為事件記錄得資訊檔案大小預設為5M，所以該方法僅適合在出現死鎖一定時間內才能查詢到（時間大概為1天左右，視資料庫使用情況而定），也可以查詢到除死鎖以為得其他資訊，待挖掘。

1.開啟 管理 > 擴充套件事件 > 會話 > system_health > package0.event_file 雙擊開啟。

2.滑鼠右鍵點選name列，選擇 在此列中查詢。

3.輸入deadlock 按回車鍵搜尋

4.檢索到死鎖資訊，滑鼠雙擊詳細資訊裡得行內容。

5.將死鎖資訊文字儲存為字尾是.xdl的檔案。

6.雙擊儲存得檔案或用sqlserver 管理器開啟，即可檢視死鎖圖形。

以上就是查詢死鎖資訊的方法，可以設定篩選，會更方便定位查詢，我覺得這個方法很便捷，大家覺得有幫助給個贊吧，欠缺的話多提意見，這樣我也有動力寫好死鎖分析文件，更新待續！

PS：在群裡有的想法不統一，思路上有分歧，可能我現在站的層面還沒達到你們那麼高，我只是一個小白，路途還很遠，還有很多要學，我只是站在小白的角度說下問題，也許錯了，在以後學習的過程中我會慢慢改正。我只是想分享下自己找問題的經驗。為以後走我這條路的人開闢條捷徑。