前言： MySQL 死鎖是一種常見的問題，指兩個(gè)或多個(gè)事務(wù)互相持有對方所需要的資源，并且都在等待對方釋放，導(dǎo)致所有事務(wù)都無法繼續(xù)執(zhí)行。以下是 MySQL 死鎖的排查方法、預(yù)防手段以及解決方式的詳細(xì)解析：

一、死鎖排查方法

1. 查看死鎖日志

MySQL 會(huì)記錄死鎖信息到錯(cuò)誤日志中，可以通過以下方式查看：

方法 1：啟用死鎖日志輸出

SHOW ENGINE INNODB STATUS;

執(zhí)行上述命令后會(huì)顯示最近一次死鎖的詳細(xì)信息，包括：

• 死鎖涉及的事務(wù)
• 每個(gè)事務(wù)鎖住的資源
• 引發(fā)死鎖的具體 SQL 語句

方法 2：檢查 MySQL 錯(cuò)誤日志

在 MySQL 的錯(cuò)誤日志文件中查找死鎖相關(guān)記錄。日志文件路徑通常在 my.cnf 的 log_error 配置項(xiàng)中指定。

示例：

LATEST DETECTED DEADLOCK
------------------------
*** (1) TRANSACTION:
TRANSACTION 12345678, ACTIVE 5 sec
LOCK WAIT 5 lock struct(s), heap size 1136, 4 row lock(s)
MySQL thread id 25, OS thread handle 139824938854144, query id 42 localhost root updating
UPDATE orders SET status='completed' WHERE id=1

*** (2) TRANSACTION:
TRANSACTION 87654321, ACTIVE 3 sec
LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 30, OS thread handle 139824938854145, query id 45 localhost root updating
UPDATE inventory SET stock=stock-1 WHERE product_id=1

2. 使用性能分析工具

MySQL Performance Schema：通過 events_waits_summary_by_instance 表分析等待的鎖。
第三方工具：如 Percona Toolkit 提供的 pt-deadlock-logger，可以定時(shí)收集死鎖信息。

二、死鎖的常見原因

1. 不同事務(wù)操作資源的順序不一致

如果兩個(gè)事務(wù)訪問相同的表和行，但操作順序不同，容易導(dǎo)致死鎖。
示例：

• 事務(wù) A：先鎖表 orders，再鎖表 inventory
• 事務(wù) B：先鎖表 inventory，再鎖表 orders

2. 鎖的范圍過大

使用 UPDATE 或 DELETE 時(shí)沒有精確的 WHERE 條件，導(dǎo)致鎖的范圍擴(kuò)大。

3. 事務(wù)持有鎖的時(shí)間過長
長時(shí)間的事務(wù)可能阻塞其他事務(wù)，增加死鎖的可能性。

4. 外鍵和級(jí)聯(lián)操作
外鍵關(guān)聯(lián)的表在更新或刪除時(shí)可能隱式加鎖，導(dǎo)致死鎖。

三、如何預(yù)防死鎖

1. 統(tǒng)一事務(wù)操作順序

確保多個(gè)事務(wù)對相同資源的訪問順序一致，可以有效降低死鎖概率。

事務(wù) A 和事務(wù) B 都按：orders → inventory 的順序訪問資源

2. 合理設(shè)計(jì) SQL

• 盡量避免全表掃描，優(yōu)化 WHERE 條件，使鎖范圍更小。
• 對可能出現(xiàn)并發(fā)的表加索引，減少鎖的粒度。

示例：

UPDATE orders SET status='completed' WHERE id=1;

為 id 字段創(chuàng)建索引以減少鎖定范圍。

3. 控制事務(wù)范圍和鎖時(shí)間

• 將事務(wù)盡量縮小到最小邏輯單元，減少鎖占用時(shí)間。
• 在事務(wù)中避免長時(shí)間操作（如網(wǎng)絡(luò)調(diào)用、用戶交互）。

4. 減少并發(fā)量

• 在高并發(fā)場景下，合理設(shè)計(jì)分布式系統(tǒng)，減少對單一資源的高頻操作。
• 使用分片技術(shù)或分布式數(shù)據(jù)庫。

5. 使用合適的隔離級(jí)別

如果業(yè)務(wù)允許，考慮將事務(wù)隔離級(jí)別從 REPEATABLE READ 降低為 READ COMMITTED，降低死鎖概率。

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

四、解決死鎖的方法

1. 定期監(jiān)控和優(yōu)化

定期通過 SHOW ENGINE INNODB STATUS 檢查死鎖日志。
使用工具（如 pt-deadlock-logger）分析死鎖頻發(fā)的 SQL，優(yōu)化相關(guān)查詢和索引。

2. 重試機(jī)制

在應(yīng)用程序中捕獲死鎖異常，添加重試邏輯。
示例：

int retries = 3;
while (retries > 0) {
    try {
        // 執(zhí)行數(shù)據(jù)庫操作
        break;
    } catch (DeadlockException e) {
        retries--;
        if (retries == 0) {
            throw e;
        }
    }
}

3. 手動(dòng)分離鎖沖突操作
將事務(wù)中可能引發(fā)死鎖的部分分離到單獨(dú)的事務(wù)中。
示例：
將庫存更新和訂單狀態(tài)更新分成兩個(gè)事務(wù)分別執(zhí)行。

4. 合理使用鎖機(jī)制

• 在需要對數(shù)據(jù)加鎖的場景，使用 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 明確加鎖的范圍。
• 在大批量操作時(shí)，可以分批處理以減少鎖時(shí)間。

示例：

SELECT * FROM orders WHERE id=1 FOR UPDATE;

5. 樂觀鎖

通過版本號(hào)或時(shí)間戳機(jī)制實(shí)現(xiàn)數(shù)據(jù)更新時(shí)的沖突檢測，避免悲觀鎖的持有。
示例：
表結(jié)構(gòu)增加 version 字段，每次更新時(shí)檢查版本號(hào)是否一致。

UPDATE orders SET status='completed', version=version+1 WHERE id=1 AND version=1;

五、實(shí)際案例分析

場景：訂單表與庫存表死鎖

• 事務(wù) A：更新訂單狀態(tài) → 更新庫存
• 事務(wù) B：更新庫存 → 更新訂單狀態(tài)

解決方案：

1、調(diào)整操作順序

所有事務(wù)統(tǒng)一按訂單表 → 庫存表的順序訪問。

2、優(yōu)化 SQL

對訂單和庫存表加索引，減少鎖定行數(shù)。

3、分離事務(wù)

將庫存更新分離為單獨(dú)的事務(wù)，減少事務(wù)持有鎖的時(shí)間。

4、合理選擇隔離級(jí)別

將事務(wù)隔離級(jí)別設(shè)置為 READ COMMITTED，避免幻讀的加鎖操作。

六、總結(jié)

排查死鎖時(shí)，通過日志和工具分析根因是關(guān)鍵；預(yù)防死鎖需要合理設(shè)計(jì)事務(wù)和 SQL；解決死鎖則可以通過重試、調(diào)整操作順序、分離事務(wù)和優(yōu)化鎖的范圍等方式。根據(jù)具體場景選擇合適的手段，才能有效避免和解決死鎖問題。

到此這篇關(guān)于MySql死鎖排查的問題解決的文章就介紹到這了,更多相關(guān)MySql死鎖排查內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！