引言

死鎖是多個事務互相持有對方需要的鎖，且都不釋放，導致互相無限等待的現(xiàn)象，MySQL 會自動檢測并終止其中一個事務（拋出死鎖異常），讓另一個正常執(zhí)行。

你現(xiàn)在的核心需求分兩步：

1. 緊急處理：已經(jīng)發(fā)生死鎖，怎么快速恢復業(yè)務？
2. 根治問題：怎么讓死鎖不再頻繁出現(xiàn)？

一、已經(jīng)產(chǎn)生死鎖：3步快速解決

1. 無需手動殺進程！MySQL 會自動處理

MySQL 內置死鎖檢測（默認開啟），一旦檢測到死鎖：

• 立即回滾代價最小的那個事務
• 給應用拋出 Deadlock found when trying to get lock; try restarting transaction 異常
• 另一個事務會自動繼續(xù)執(zhí)行，死鎖瞬間解除

結論：已發(fā)生的死鎖不需要人工干預，MySQL 自己會秒級解決。

2. 查看死鎖日志：找到根源（最重要）

死鎖已經(jīng)發(fā)生，必須查日志定位原因，執(zhí)行命令：

-- 查看最近一次死鎖的詳細信息
SHOW ENGINE INNODB STATUS;

在結果中找到 LATEST DETECTED DEADLOCK 段落，里面會告訴你：

• 哪兩個事務死鎖了
• 各自執(zhí)行的 SQL
• 各自持有什么鎖、等待什么鎖
• 死鎖發(fā)生的時間

這是解決死鎖的唯一依據(jù)。

3. 臨時應急：卡住的事務不自動解除？

極少數(shù)情況（關閉了死鎖檢測），事務會一直卡住，執(zhí)行以下命令手動處理：

-- 1. 查看正在運行的事務，找到卡住的 ID
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

-- 2. 殺掉卡住的事務
KILL 事務ID;

二、永久避免死鎖：4個核心方案（必做）

死鎖無法100%杜絕，但99%的死鎖都能通過規(guī)范避免。

1. 事務保持短小，不要長事務

• 死鎖概率和事務執(zhí)行時間成正比
• 禁止在事務里嵌套：網(wǎng)絡請求、文件IO、人工操作、sleep
• 原則：快進快出，執(zhí)行完立即提交/回滾

壞例子

BEGIN;
UPDATE 表 SET ...;
-- 這里調用了外部接口，耗時3秒，鎖一直持有，極易死鎖
COMMIT;

2. 所有表固定訪問順序（最有效）

死鎖的本質：訪問順序相反

• 事務A：先鎖訂單 → 再鎖庫存
• 事務B：先鎖庫存 → 再鎖訂單
  → 瞬間死鎖

解決方案：
所有業(yè)務代碼，必須按相同順序操作表/行
例如：統(tǒng)一先操作庫存，再操作訂單。

3. 給查詢條件加索引

無索引會導致行鎖升級為表鎖，死鎖概率暴增。

-- 錯誤：無索引，會鎖全表
UPDATE user SET money=100 WHERE name='張三'; 

-- 正確：name 有索引，只鎖單行
UPDATE user SET money=100 WHERE name='張三'; 

死鎖日志里如果看到 LOCK_MODE: X, REC_NOT_GAP: nil 基本就是無索引導致。

4. 業(yè)務代碼捕獲死鎖異常，自動重試

死鎖是偶發(fā)異常，重試就能成功，這是兜底方案。

Java 示例：

try {
    // 執(zhí)行數(shù)據(jù)庫操作
} catch (SQLTransactionRollbackException e) {
    if (e.getMessage().contains("Deadlock")) {
        // 死鎖異常，重試1-2次
        retry();
    }
}

三、快速排查死鎖 Checklist

1. 執(zhí)行 SHOW ENGINE INNODB STATUS; 看死鎖詳情
2. 檢查兩個事務是否訪問表/行順序相反
3. 檢查更新語句是否沒有索引
4. 檢查是否有長事務
5. 業(yè)務代碼是否沒有重試機制

總結

1. 已產(chǎn)生的死鎖：MySQL 自動回滾一個事務，無需手動處理
2. 查死鎖原因：用 SHOW ENGINE INNODB STATUS;
3. 根治死鎖：固定訪問順序 + 加索引 + 短事務 + 代碼重試
4. 兜底：業(yè)務捕獲死鎖異常自動重試，用戶無感知

到此這篇關于MySQL已產(chǎn)生死鎖的解決方法及永久避免方案的文章就介紹到這了,更多相關MySQL已產(chǎn)生死鎖解決與避免內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論