前言
數據庫死鎖問題是我們老生常談的問題了，在我們實際開發過程中經常會遇到，為了盡量避免出現死鎖，我們需要了解出現死鎖的場景。同時，如果線上出現了死鎖之后怎么去分析、排查和解決，下面我就這兩點介紹一下。
一、數據庫死鎖介紹
1、什么是數據庫死鎖？
數據庫的死鎖是指：不同的事務在獲取資源時相互等待，導致無法繼續執行的一種情況。當發生死鎖時，數據庫系統會自動中斷其中一個事務，以解除死鎖。在數據庫中，事務可以分為讀事務和寫事務。讀事務只需要獲取讀鎖，而寫事務需要獲取寫鎖。當多個事務同時操作同一組數據時，可能會引發死鎖的出現。
2、MySQL 發生死鎖的場景
2-1、事務同時更新多個表
當一個事務同時更新多個表并且使用了不同的順序，可能會導致死鎖的發生。例如，事務 A 首先更新表 X，此時獲取到了 X 表的鎖，并在未釋放該鎖的情況下嘗試更新表 Y；而事務 B 首先更新表Y，此時獲取到了 Y 表的鎖，并在未釋放鎖的情況下嘗試更新表 X。這種情況下，兩個事務會相互等待對方的鎖釋放，從而形成死鎖。
2-2、事務嵌套
當一個事務內部開啟了另一個事務，并在內層事務中更新了某個表，而外層事務也需要更新該表的同一行記錄時，就有可能發生死鎖。因為外層事務需要等待內層事務釋放鎖，而內層事務需要等待外層事務釋放鎖。
2-3、索引順序不一致
當多個事務按照不同的順序訪問相同的數據行，并且使用了不同的索引時，可能會發生死鎖。例如，事務 A 按照索引 1 的順序訪問數據行，事務 B 按照索引 2 的順序訪問同一組數據行，這樣兩個事務之間就會產生死鎖。
2-4、不同事務同時更新相同的索引
當多個事務同時更新相同的索引時，可能會導致死鎖。這是因為事務在更新索引時會獲取對應的鎖，并在未釋放鎖的情況下嘗試更新其他數據，從而形成死鎖。
二、解決死鎖問題
如果線上發生了死鎖，我們應該采取以下步驟進行處理：
1、 監控死鎖
正常情況下我們都會建立死鎖監控機制，以便及時掌握死鎖情況；同時設置相應的預警機制，以便在死鎖發生時能夠及時處理。
通過數據庫的監控工具或命令可以查看是否存在死鎖情況，如果出現則了解死鎖的具體情況，包括死鎖的事務和死鎖的資源。
2、終止死鎖事務
根據監控結果，找到造成死鎖的事務，并手動選擇其中一個事務終止。可以根據事務的執行時間、影響行數、優先級等因素進行終止決策。可以通過 select * from information_schema.innodb_trx 語句查看死鎖情況。
在 innodb 中，有三張表可以幫助我們更好去分析死鎖信息：
- information_schema.innodb_trx：事務信息表。
- information_schema.innodb_locks：事務鎖的信息表。
- information_schema.innodb_lock_waits：鎖等待關系表。
系統自動解除死鎖：
正常情況下，當發生死鎖時，MySQL 系統會自動解除死鎖，至于解除哪個事務的鎖，需要虧了一個代價，在解除死鎖方面，會選擇回滾事務產生影響最小的一個進行回滾。
這里就要提一下兩個概念了，一個是事務的權重（trx_weight），另外一個是事務的調度權重（trx_schedule_weight）：
- 事務的權重：與回滾事務的選擇有關。具體與事務 undo 版本鏈的長度有關，回滾的 undo 記錄越多，產生的影響就會越大，MySQL 就不會選擇這樣的事務，倘若事務權重一樣，會選擇事務等待隊列等待時間短的事務進行回滾。
- 事務的調度權重：與事務獲取資源的先后有關。MySQL8.0.20 之前在等待鎖的事務優先級排序采取 FIFO 算法，之后采取 CATS 算法。該算法通過分配調度權限對等待的事務進行優先級排序，該權重是根據事務阻塞的事務數量計算的。例如，兩個事務正在等待同一對象上的鎖，那么阻塞最多事務的事務將被分配更大的調度權重，如果權重相等，則優先考慮等待時間最長的事務分配資源。
3、重試事務
終止死鎖事務后，需要重新執行被終止的事務。這可能需要一些邏輯處理，例如對數據進行回滾或者重新執行一些操作。
4、分析死鎖原因
通過數據庫的日志和監控信息，分析死鎖的原因。下面是查看死鎖日志的命令語句：
show engine innodb status;
分析死鎖日志然后根據死鎖原因對數據庫的設計和代碼進行優化，以盡量減少死鎖的發生。
同時也可以根據分析結果，針對性地進行數據庫結構調整、索引優化、事務隔離級別調整等措施，以降低死鎖的概率。
5、避免死鎖建議
- 事務盡可能小，不要將復雜邏輯放進一個事務里。
- 涉及多行記錄時，約定不同事務以相同順序訪問。
- 業務中要及時提交或者回滾事務，可減少死鎖產生的概率。
- 表要有合適的索引。
- 可嘗試將隔離級別改為 ReadCommit 。
——9)
)
