線上發生死鎖異常了，該怎麼辦

點擊上方"程序員歷小冰"，選擇「置頂或者星標」mysql

你的關注意義重大!
程序員

前言

MySQL 死鎖異常是咱們常常會遇到的線上異常類別，一旦線上業務日間複雜，各類業務操做之間每每會產生鎖衝突，有些會致使死鎖異常。這種死鎖異常通常要在特定時間特定數據和特定業務操做纔會復現，而且分析解決時還須要瞭解 MySQL 鎖衝突相關知識，因此通常遇到這些偶爾出現的死鎖異常，每每一時沒有頭緒，很差處理。web

本篇文章會講解一下若是線上發生了死鎖異常，如何去排查和處理。除了系列前文講解的有關加鎖和鎖衝突的原理還，還須要對 MySQl 死鎖日誌和 binlog 日誌進行分析。sql

正文

平常工做中，應對各種線上異常都要有咱們本身的 SOP (標準做業流程) ，這樣不只可以提升本身的處理問題效率，也有助於將好的處理流程推廣到團隊，提升團隊的總體處理異常能力。數據庫

因此，面對線上偶發的 MySQL 死鎖問題，個人排查處理過程以下：bash

線上錯誤日誌報警發現死鎖異常微信

查看錯誤日誌的堆棧信息運維

查看 MySQL 死鎖相關的日誌分佈式

根據 binlog 查看死鎖相關事務的執行內容ide

根據上述信息找出兩個相互死鎖的事務執行的 SQL 操做，根據本系列介紹的鎖相關理論知識，進行分析推斷死鎖緣由

修改業務代碼

根據1，2步驟能夠找到死鎖異常時進行回滾事務的具體業務，也就可以找到該事務執行的 SQL 語句。而後咱們須要經過 3，4步驟找到死鎖異常時另一個事務，也就是最終得到鎖的事務所執行的 SQL 語句，而後再進行鎖衝突相關的分析。

第一二步的線上錯誤日誌和堆棧信息通常比較容易得到，第五步的分析 SQL 鎖衝突緣由中涉及的鎖相關的理論在系列文章中都有介紹，沒有了解的同窗能夠自行去閱讀如下。

下面咱們就來重點說一下其中的第三四步驟，也就是如何查看死鎖日誌和 binlog 日誌來找到死鎖相關的 SQL 操做。

死鎖日誌的獲取

發生死鎖異常後，咱們能夠直接使用 show engine innodb status 命令獲取死鎖信息，可是該命令只能獲取最近一次的死鎖信息。因此，咱們能夠經過開啓 InnoDB 的監控機制來獲取實時的死鎖信息，它會週期性（每隔 15 秒）打印 InnoDb 的運行狀態到 mysqld 服務的錯誤日誌文件中。

InnoDb 的監控較爲重要的有標準監控（Standard InnoDB Monitor）和鎖監控（InnoDB Lock Monitor），經過對應的系統參數能夠將其開啓。

另外，MySQL 提供了一個系統參數 innodb_print_all_deadlocks 專門用於記錄死鎖日誌，當發生死鎖時，死鎖日誌會記錄到 MySQL 的錯誤日誌文件中。

set GLOBAL innodb_print_all_deadlocks=ON;

死鎖日誌的分析

經過上述手段，咱們能夠拿到死鎖日誌，下圖是我作實驗觸發死鎖異常時獲取的日誌(省略的部分信息)。

該日誌會列出死鎖發生的時間，死鎖相關的事務，並顯示出兩個事務(惋惜，多事務發生死鎖時，也只顯示兩個事務)在發生死鎖時執行的 SQL 語句、持有或等待的鎖信息和最終回滾的事務。

下面，咱們來一段一段的解讀該日誌中給出的信息，咱們按照圖中標註的順序來介紹：

TRANSACTION 2078, ACTIVE 74 sec starting index read // -1 事務一的基礎信息，包括事務ID、活躍時間，當前運行狀態

表示的是 ACTIVE 74 sec 表示事務活動時間，starting index read 爲事務當前正在運行的狀態，可能的事務狀態有：fetching rows，updating，deleting，inserting, starting index read 等狀態。

其中第一行，tables in use 1 表示有一個表被使用，locked 1 表示有一個表鎖。第二行中的 LOCK WAIT 表示事務正在等待鎖，3 lock struct(s) 表示該事務的鎖鏈表的長度爲 3，每一個鏈表節點表明該事務持有的一個鎖結構，包括表鎖，記錄鎖或 autoinc 鎖等。heap size 1136 爲事務分配的鎖堆內存大小。

第二行後半段中，2 row lock(s) 表示當前事務持有的行鎖個數，經過遍歷上面提到的 11 個鎖結構，找出其中類型爲 LOCK_REC 的記錄數。undo log entries 1 表示當前事務有 1 個 undo log 記錄，說明該事務已經更新了 1條記錄。

下面就是死鎖日誌中最爲重要的持有或者待獲取鎖信息，如圖中-5和-6行所示，經過它能夠分析鎖的具體類型和涉及的表，這些信息能輔助你按照系列文章的鎖相關的知識來分析 SQL 的鎖衝突。

在《鎖類型和加鎖原理》一文中咱們說過，一共有四種類型的行鎖：記錄鎖，間隙鎖，Next-key 鎖和插入意向鎖。這四種鎖對應的死鎖日誌各不相同，以下：

記錄鎖（LOCK_REC_NOT_GAP）: lock_mode X locks rec but not gap
間隙鎖（LOCK_GAP）: lock_mode X locks gap before rec
Next-key 鎖（LOCK_ORNIDARY）: lock_mode X
插入意向鎖（LOCK_INSERT_INTENTION）: lock_mode X locks gap before rec insert intention

因此，按照死鎖日誌，咱們發現事務一持有了 test.t 表上的記錄鎖，而且等待另外一個記錄鎖。

經過死鎖日誌，咱們能夠找到最終得到鎖事務最後執行的 SQL，可是若是該事務執行了多條 SQL，這些信息就可能不夠用的啦，咱們須要完整的瞭解該事務全部執行的 SQL語句。這時，咱們就須要從 binlog 日誌中獲取。

binlog的獲取和分析

binlog 日誌會完整記錄事務執行的全部 SQL，藉助它，咱們就能找到最終獲取鎖事務所執行的所有 SQL。而後再進行具體的鎖衝突分析。

咱們可使用 MySQL 的命令行工具 Mysqlbinlog 遠程獲取線上數據庫的 binlog 日誌。具體命令以下所示：

Mysqlbinlog -h127.0.0.1 -u root -p --read-from-remote-server binlog.000001 --base64-output=decode-rows -v

其中 --base64-output=decode-rows 表示 row 模式 binlog日誌，因此該方法只適用於 row 模式的 binlog日誌，可是目前主流 MySQL 運維也都是把 binlog 日誌設置爲 row 模式，因此這點限制也就無傷大雅。-v 則表示將行事件重構成被註釋掉的僞SQL語句。

咱們能夠經過死鎖日誌中死鎖發生的具體事件和最終獲取鎖事務正在執行的SQL的參數信息找到 binlog 中該事務的對應信息，好比咱們能夠直接經過死鎖日誌截圖中的具體的時間 10點57分和 Tom一、Teddy2 等 SQL 的具體數據信息在 binlog 找到對應的位置，具體以下圖所示。

根據 binlog 的具體信息，咱們能夠清晰的找到最終獲取鎖事務所執行的全部 SQL 語句，也就能找到其對應的業務代碼，接下來咱們就能進行具體的鎖衝突分析。

小結

死鎖系列終於告一段落，若是大夥有什麼疑問或者文中有什麼錯誤，歡迎在下方留言討論。也但願你們繼續持續關注。

-關注我