1. 死鎖的發(fā)生

1.1 什么是死鎖？

死鎖是指兩個或多個事務(wù)在并發(fā)執(zhí)行時，因為資源互相占用而進入一種無限等待的狀態(tài)，導(dǎo)致無法繼續(xù)執(zhí)行的現(xiàn)象。

例如：

• 事務(wù)A持有資源1，同時請求資源2。
• 事務(wù)B持有資源2，同時請求資源1。兩者互相等待對方釋放資源，最終導(dǎo)致死鎖。

1.2 死鎖發(fā)生的條件

死鎖的發(fā)生必須滿足以下四個條件：

1. 互斥條件：某些資源只能被一個事務(wù)占用。
2. 請求與保持條件：事務(wù)在等待其他資源時，保持已占有的資源。
3. 不可剝奪條件：事務(wù)已獲得的資源在事務(wù)完成之前不能被強行剝奪。
4. 循環(huán)等待條件：事務(wù)之間形成環(huán)形等待鏈。

1.3 死鎖的典型場景

以下是常見的死鎖場景：

兩個事務(wù)互相等待：

• 事務(wù)A在表table1上鎖，事務(wù)B在表table2上鎖。
• 事務(wù)A請求table2的鎖，同時事務(wù)B請求table1的鎖。

同一表的并發(fā)更新：

• 事務(wù)A鎖住記錄1，事務(wù)B鎖住記錄2，之后A請求記錄2的鎖，而B請求記錄1的鎖。

2. 為什么會產(chǎn)生死鎖？

2.1 事務(wù)隔離級別與并發(fā)控制

在MySQL中，為了保證數(shù)據(jù)一致性，數(shù)據(jù)庫通過事務(wù)隔離級別來控制并發(fā)操作中的數(shù)據(jù)訪問方式。事務(wù)隔離級別主要包括：

• 讀未提交（Read Uncommitted）：不加鎖，允許“臟讀”，不會產(chǎn)生死鎖。
• 讀已提交（Read Committed）：讀時加共享鎖，可能產(chǎn)生死鎖。
• 可重復(fù)讀（Repeatable Read）：讀時加間隙鎖或行鎖，可能產(chǎn)生死鎖。
• 序列化（Serializable）：事務(wù)完全串行化執(zhí)行，雖然不會死鎖，但性能非常低。

在高并發(fā)環(huán)境中，如果多個事務(wù)同時對同一資源進行操作，而它們的操作順序不一致，可能會導(dǎo)致死鎖。

2.2 死鎖的根本原因

資源競爭

死鎖的最主要原因是多個事務(wù)爭奪同一資源，比如行鎖或表鎖。

示例：

事務(wù)A對記錄X加鎖，事務(wù)B對記錄Y加鎖，隨后兩者同時請求對方已加鎖的記錄。

鎖的申請順序不一致

如果兩個事務(wù)以不同的順序申請鎖，可能形成循環(huán)等待。

示例：

• 事務(wù)A先鎖住記錄1，再請求記錄2。
• 事務(wù)B先鎖住記錄2，再請求記錄1。

間隙鎖的引入

在可重復(fù)讀隔離級別下，MySQL會使用間隙鎖來避免幻讀。當(dāng)多個事務(wù)嘗試修改或插入相鄰范圍的數(shù)據(jù)時，可能發(fā)生死鎖。

• 示例：事務(wù)A和事務(wù)B同時對相鄰的范圍加鎖后試圖插入重疊范圍的數(shù)據(jù)。

3. 為什么間隙鎖與間隙鎖之間是兼容的？

3.1 什么是間隙鎖（Gap Lock）？

間隙鎖是MySQL InnoDB引擎在可重復(fù)讀（Repeatable Read）隔離級別下引入的一種鎖機制，用于鎖定某個記錄之間的間隙，以防止其他事務(wù)在這個間隙中插入數(shù)據(jù)，從而避免幻讀問題。

例如：

如果表中有以下記錄：

| id |
|----|
|  1 |
|  5 |
| 10 |

當(dāng)事務(wù)A執(zhí)行SELECT * FROM table WHERE id > 5 FOR UPDATE時，InnoDB會鎖定記錄id=5到id=10之間的間隙，稱為間隙鎖。

3.2 為什么間隙鎖與間隙鎖之間是兼容的？

間隙鎖的設(shè)計初衷是防止插入數(shù)據(jù)造成的不一致，而不是為了互相排他。因此，多個事務(wù)可以同時對同一間隙加鎖。

原因如下：

間隙鎖不鎖定具體的行

• 它僅鎖定記錄之間的間隙，并不會阻止現(xiàn)有記錄的更新或刪除。
• 比如，事務(wù)A和事務(wù)B都可以鎖住(id=5, id=10)的間隙，但彼此不會阻塞。

間隙鎖的目的只是防止插入

• 如果間隙鎖之間不兼容，任何查詢操作都會互相阻塞，降低并發(fā)性能。
• 兼容性允許事務(wù)讀取相同的間隙，而只阻止插入。

示例：

• 事務(wù)A和事務(wù)B都對間隙(id=5, id=10)加鎖。
• 此時，兩者可以同時執(zhí)行查詢，但若事務(wù)C嘗試向這個間隙插入新記錄，則會被阻塞。

小結(jié)

間隙鎖之間的兼容性是為了提高并發(fā)性能，同時確保數(shù)據(jù)的一致性和隔離性。在解決幻讀問題的同時，不會額外增加事務(wù)的等待時間。

4. 插入意向鎖是什么？

4.1 插入意向鎖的定義

插入意向鎖（Insert Intention Lock）是MySQL InnoDB引擎在執(zhí)行插入操作時加上的一種特殊的間隙鎖，用來表明當(dāng)前事務(wù)有意在某個間隙中插入數(shù)據(jù)。

插入意向鎖是共享鎖的一種，多個事務(wù)可以同時在一個間隙上設(shè)置插入意向鎖，因為它們彼此之間并不沖突。這種設(shè)計允許多個事務(wù)同時嘗試在不同位置插入記錄，從而提高并發(fā)性能。

4.2 插入意向鎖的作用

插入意向鎖的主要目的是協(xié)調(diào)插入操作與其他間隙鎖之間的關(guān)系，以確保數(shù)據(jù)一致性并避免沖突。

• 如果另一個事務(wù)已經(jīng)對某個間隙加了間隙鎖，插入意向鎖會被阻塞，直到間隙鎖釋放。
• 如果沒有間隙鎖，多個事務(wù)可以同時設(shè)置插入意向鎖，并在不同的位置插入數(shù)據(jù)。

4.3 插入意向鎖的典型場景

兩個事務(wù)同時插入數(shù)據(jù)但位置不同：

• 表中已有記錄：1, 5, 10。
• 事務(wù)A嘗試插入id=3，事務(wù)B嘗試插入id=7。
• 兩者都會在各自的間隙上加插入意向鎖，互不沖突，插入成功。

兩個事務(wù)插入數(shù)據(jù)但位置沖突：

• 表中已有記錄：1, 5, 10。
• 事務(wù)A嘗試插入id=3，事務(wù)B也嘗試插入id=3。
• 此時，兩者的插入意向鎖會發(fā)生沖突，其中一個事務(wù)需等待另一個事務(wù)完成插入并釋放鎖。

4.4 插入意向鎖與間隙鎖的關(guān)系

• 插入意向鎖是為了協(xié)調(diào)插入操作與間隙鎖之間的關(guān)系。
• 當(dāng)一個事務(wù)對某個間隙加了間隙鎖時，其他事務(wù)的插入意向鎖會被阻塞，直到間隙鎖釋放。
• 如果間隙未被鎖定，插入意向鎖之間互不沖突。

示例：

以下是表中已有記錄的情況：

| id |
|----|
|  1 |
|  5 |
| 10 |

事務(wù)A執(zhí)行：INSERT INTO table (id) VALUES (3);

• 事務(wù)A對間隙(id=1, id=5)加插入意向鎖。

事務(wù)B執(zhí)行：INSERT INTO table (id) VALUES (7);

• 事務(wù)B對間隙(id=5, id=10)加插入意向鎖。

兩者不沖突，因此可以并發(fā)插入。如果事務(wù)C對整個間隙(id=1, id=10)加間隙鎖，則A和B會被阻塞。

5. Insert 語句是如何加行級鎖的？

5.1 Insert 語句加鎖機制概述

在 MySQL 中，Insert 語句會通過加鎖機制確保并發(fā)事務(wù)的安全性和一致性。在默認的 InnoDB 存儲引擎中，Insert 操作的鎖類型取決于具體的操作場景，包括：

• 插入行級鎖：保護新插入的記錄，防止其他事務(wù)對這些記錄進行沖突操作。
• 插入意向鎖：保護插入目標(biāo)位置的間隙，協(xié)調(diào)插入操作與其他事務(wù)的鎖。

5.2 Insert 語句加鎖的工作流程

檢查目標(biāo)位置的鎖狀態(tài)：

• 如果目標(biāo)間隙未被其他事務(wù)加鎖，Insert 操作直接進行，并加插入意向鎖和行級鎖。
• 如果目標(biāo)間隙已經(jīng)被其他事務(wù)加間隙鎖，當(dāng)前事務(wù)需要等待間隙鎖釋放。

加插入意向鎖：

• 在目標(biāo)間隙加插入意向鎖，用于標(biāo)識事務(wù)有意向在此間隙插入數(shù)據(jù)。多個事務(wù)可以同時加插入意向鎖（前提是插入位置不沖突）。

插入新記錄并加行級鎖：

• 成功插入后，對新記錄加行級鎖（排他鎖，Exclusive Lock），防止其他事務(wù)對該記錄進行修改。

5.3 插入唯一鍵記錄的特殊加鎖場景

唯一鍵沖突：

• 如果插入的記錄包含唯一鍵約束，MySQL 在插入前會檢查表中是否已存在沖突記錄。
• 若存在沖突記錄，則會對該記錄加行級鎖，阻止其他事務(wù)對該記錄進行并發(fā)操作。

示例：

• 表中已有記錄id=5。
• 事務(wù)A嘗試插入id=5，此時會對記錄id=5加排他鎖，導(dǎo)致其他事務(wù)的插入或更新操作阻塞。

隱式鎖機制（后續(xù)詳細介紹）：

• 如果唯一鍵沖突的檢查范圍較大，可能會對不必要的記錄加鎖，導(dǎo)致死鎖風(fēng)險增加。

5.4 插入語句鎖沖突的典型示例

表結(jié)構(gòu)如下：

CREATE TABLE test_table ( id INT PRIMARY KEY, value VARCHAR(100) );

無鎖沖突：

• 事務(wù)A：INSERT INTO test_table (id, value) VALUES (2, 'A');
• 事務(wù)B：INSERT INTO test_table (id, value) VALUES (3, 'B');
• 因為插入目標(biāo)位置不同，事務(wù)A和事務(wù)B的插入意向鎖不會沖突。

鎖沖突場景：

• 事務(wù)A：INSERT INTO test_table (id, value) VALUES (5, 'A');（成功插入并加鎖）。
• 事務(wù)B：INSERT INTO test_table (id, value) VALUES (5, 'B');（沖突，事務(wù)B被阻塞，等待事務(wù)A提交或回滾）。

小結(jié)

Insert 操作的鎖機制主要包括插入意向鎖和行級鎖，目的是確保并發(fā)插入的安全性。當(dāng)唯一鍵沖突時，MySQL會對沖突記錄加鎖，這也是死鎖產(chǎn)生的常見原因之一。

6. 什么是隱式鎖？

6.1 隱式鎖的定義

隱式鎖（Implicit Lock）是 MySQL InnoDB 存儲引擎在事務(wù)中自動加上的一種鎖，而不需要用戶顯式地指定。隱式鎖主要用于記錄級鎖（Record Lock）和間隙鎖（Gap Lock）的管理，用來維護數(shù)據(jù)的一致性。

InnoDB 的隱式鎖由存儲引擎在后臺 完成，用戶看不到這些鎖的具體表現(xiàn)形式，通常它的加鎖過程伴隨事務(wù)語句的執(zhí)行自動發(fā)生。

6.2 隱式鎖的特點

自動管理：

隱式鎖是 MySQL 的事務(wù)引擎根據(jù)事務(wù)的隔離級別和執(zhí)行語句決定的，用戶無需干預(yù)。

不可見性：

隱式鎖不會直接暴露給用戶，用戶通常通過分析事務(wù)的行為或使用 MySQL 的鎖監(jiān)控工具（如SHOW ENGINE INNODB STATUS）來間接觀察隱式鎖的存在。

分為記錄鎖和間隙鎖：

隱式鎖既可以是針對具體記錄的鎖（Record Lock），也可以是針對間隙的鎖（Gap Lock）。

6.3 隱式鎖的工作機制

隱式鎖的加鎖行為取決于以下兩個主要場景：

記錄之間加間隙鎖（Gap Lock）：

在 REPEATABLE READ 隔離級別下，InnoDB 為了防止幻讀，會對記錄之間的間隙加鎖，阻止其他事務(wù)在這些間隙中插入新記錄。

示例：

表中已有記錄：id=1 和 id=5。

• 事務(wù)A查詢范圍：SELECT * FROM table WHERE id BETWEEN 1 AND 5 FOR UPDATE;
• MySQL 會對間隙 (1, 5) 加一個隱式間隙鎖，防止其他事務(wù)插入如 id=3 這樣的記錄。

唯一鍵沖突時：

當(dāng)一個事務(wù)插入的數(shù)據(jù)與現(xiàn)有記錄的唯一鍵沖突時，MySQL 會隱式地對沖突記錄加行級鎖，以保護沖突記錄。

示例：

表中已有記錄：id=5。

• 事務(wù)A執(zhí)行：INSERT INTO table (id, value) VALUES (5, 'A');
• MySQL 會對現(xiàn)有記錄 id=5 加一個隱式的排他鎖（Exclusive Lock），防止其他事務(wù)修改或刪除該記錄。

6.4 隱式鎖與顯式鎖的區(qū)別

6.5 死鎖相關(guān)場景

隱式鎖可能導(dǎo)致死鎖，尤其是在以下兩種場景下：

記錄之間的間隙鎖沖突：

• 事務(wù)A和事務(wù)B嘗試在同一個間隙中插入不同的數(shù)據(jù)，導(dǎo)致死鎖。

唯一鍵沖突：

• 當(dāng)兩個事務(wù)插入相同的唯一鍵記錄時，隱式鎖會同時嘗試加鎖沖突記錄，進而造成死鎖。

6.6 隱式鎖的兩種典型場景

6.6.1 場景一：記錄之間加間隙鎖

間隙鎖（Gap Lock） 是隱式鎖的重要組成部分，用于保護記錄之間的空隙，防止其他事務(wù)在這些間隙中插入新記錄。間隙鎖的存在主要與 MySQL 的隔離級別有關(guān)，在 REPEATABLE READ 下使用間隙鎖可以防止“幻讀”現(xiàn)象。

典型示例

表結(jié)構(gòu)：

CREATE TABLE test_table ( id INT PRIMARY KEY, value VARCHAR(100) );

數(shù)據(jù)初始化：

INSERT INTO test_table (id, value) VALUES (1, 'A'), (5, 'B');

場景：

事務(wù)A：執(zhí)行查詢，并鎖定范圍 (1, 5)。

START TRANSACTION; SELECT * FROM test_table WHERE id BETWEEN 1 AND 5 FOR UPDATE;

效果： MySQL 會對間隙 (1, 5) 加間隙鎖，防止其他事務(wù)在此范圍內(nèi)插入新記錄。

事務(wù)B：嘗試在間隙中插入一條記錄 id=3。

INSERT INTO test_table (id, value) VALUES (3, 'C');

結(jié)果： 事務(wù)B被阻塞，直到事務(wù)A提交或回滾。

鎖的行為：

• 事務(wù)A的鎖： 對 id=1 和 id=5 加記錄鎖，同時對間隙 (1, 5) 加間隙鎖。
• 事務(wù)B的鎖： 需要獲取 (1, 5) 的插入鎖，但被事務(wù)A的間隙鎖阻塞。

6.6.2 場景二：唯一鍵沖突

當(dāng)事務(wù)嘗試插入一條記錄，并且該記錄的主鍵或唯一鍵已經(jīng)存在時，MySQL 會對沖突的記錄加行級鎖，保護該記錄不被其他事務(wù)修改。這種行為也由隱式鎖實現(xiàn)。

典型示例

表結(jié)構(gòu)：

CREATE TABLE test_table ( id INT PRIMARY KEY, value VARCHAR(100) );

數(shù)據(jù)初始化：

INSERT INTO test_table (id, value) VALUES (5, 'B');

場景：

事務(wù)A：嘗試插入一條記錄 id=5（與現(xiàn)有記錄沖突）。

START TRANSACTION; INSERT INTO test_table (id, value) VALUES (5, 'C');

效果： MySQL 檢測到唯一鍵沖突，會對現(xiàn)有記錄 id=5 加排他鎖。

事務(wù)B：嘗試更新或刪除沖突的記錄 id=5。

START TRANSACTION; UPDATE test_table SET value='D' WHERE id=5;

結(jié)果： 事務(wù)B被阻塞，直到事務(wù)A提交或回滾。

鎖的行為：

• 事務(wù)A的鎖： 對沖突記錄 id=5 加排他鎖。
• 事務(wù)B的鎖： 嘗試獲取 id=5 的鎖時被阻塞。

6.6.3 總結(jié)隱式鎖的兩種場景

隱式鎖的這兩種場景，特別是在并發(fā)場景中，可能導(dǎo)致事務(wù)等待或死鎖，需要在應(yīng)用設(shè)計時格外注意。

7. 如何避免死鎖？

在 MySQL 的并發(fā)事務(wù)處理中，雖然完全避免死鎖不現(xiàn)實，但可以通過優(yōu)化設(shè)計和合理操作，大幅降低死鎖發(fā)生的概率。以下從 SQL 設(shè)計、事務(wù)管理和鎖機制優(yōu)化三個方面進行詳細講解。

7.1 SQL 設(shè)計中的避免死鎖方法

保持表訪問順序一致

如果多個事務(wù)操作相同的表，確保它們按照相同的順序訪問資源。例如：

如果事務(wù)A先更新表 table1，再更新表 table2，則事務(wù)B也應(yīng)按相同順序操作。

好處： 避免了交叉等待，減少死鎖風(fēng)險。

減少復(fù)雜查詢

避免過于復(fù)雜的查詢語句，因為復(fù)雜查詢可能會隱式加多個鎖，增加鎖沖突的概率。

示例：分解一個復(fù)雜查詢：

-- 原復(fù)雜查詢
UPDATE orders SET status = 'completed' WHERE user_id IN (SELECT id FROM users WHERE age > 30);
-- 拆解后
SELECT id INTO temp_table FROM users WHERE age > 30;
UPDATE orders SET status = 'completed' WHERE user_id IN (SELECT id FROM temp_table);

減少掃描范圍

限制查詢的鎖定范圍，避免全表掃描帶來的大范圍加鎖。

示例：

-- 不推薦，全表掃描
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
-- 推薦，索引范圍掃描
SELECT * FROM orders WHERE id BETWEEN 100 AND 200 AND status = 'pending' FOR UPDATE;

7.2 事務(wù)管理中的避免死鎖方法

減少事務(wù)的持鎖時間

避免在事務(wù)中執(zhí)行不必要的操作，比如事務(wù)中包含過多計算或與數(shù)據(jù)庫無關(guān)的邏輯。

優(yōu)化策略：

• 將計算邏輯移到事務(wù)外部。
• 減少事務(wù)中鎖定資源的時間。

示例：

// 不推薦：事務(wù)中包含計算
transaction {
    int sum = complexCalculation();
    db.update("UPDATE table SET value = ?", sum);
}

// 推薦：將計算移到事務(wù)外
int sum = complexCalculation();
transaction {
    db.update("UPDATE table SET value = ?", sum);
}

合理拆分事務(wù)

將一個長事務(wù)拆分為多個小事務(wù)，盡量減少事務(wù)中加鎖的資源范圍。

注意： 拆分事務(wù)時，需保證業(yè)務(wù)邏輯的一致性。

選擇合適的隔離級別

• 在對事務(wù)一致性要求不高的場景下，可以降低隔離級別（如使用 READ COMMITTED）以減少鎖沖突。

隔離級別與死鎖的關(guān)系：

• REPEATABLE READ： 更高的鎖粒度，容易死鎖。
• READ COMMITTED： 減少間隙鎖，降低死鎖概率。

7.3 鎖機制優(yōu)化中的避免死鎖方法

合理使用索引

• 沒有索引的查詢會觸發(fā)全表掃描，加鎖范圍擴大，增加死鎖概率。
• 確保查詢條件中使用索引列。

謹慎使用鎖模式

盡量避免使用 SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE，如果可能，使用更輕量級的鎖機制（如樂觀鎖）。

樂觀鎖示例：

-- 使用版本號實現(xiàn)樂觀鎖
UPDATE table
SET value = ?, version = version + 1
WHERE id = ? AND version = ?;

減少鎖范圍

通過限制查詢條件或分批處理，減少鎖定的行數(shù)。

示例：

-- 不推薦，鎖住整個表
DELETE FROM orders WHERE status = 'pending';

-- 推薦，分批刪除
DELETE FROM orders WHERE status = 'pending' LIMIT 100;

監(jiān)控鎖的狀態(tài)

使用 MySQL 提供的工具監(jiān)控鎖的狀態(tài)，及時發(fā)現(xiàn)潛在的死鎖問題：

• SHOW ENGINE INNODB STATUS：查看死鎖信息。
• INFORMATION_SCHEMA.INNODB_LOCKS：分析當(dāng)前持鎖和等待鎖的事務(wù)。

7.4 避免死鎖的實戰(zhàn)總結(jié)

8. 死鎖的監(jiān)控與調(diào)試

盡管通過優(yōu)化設(shè)計和事務(wù)管理可以有效減少死鎖的發(fā)生，但在實際生產(chǎn)環(huán)境中，死鎖仍然不可避免地時常發(fā)生。因此，監(jiān)控和調(diào)試死鎖問題成為數(shù)據(jù)庫管理中的一項重要任務(wù)。了解如何有效監(jiān)控、分析死鎖，并能夠快速定位和解決問題，能有效提高系統(tǒng)的穩(wěn)定性和性能。

8.1 如何監(jiān)控 MySQL 中的死鎖

MySQL 提供了幾種方式來監(jiān)控死鎖的發(fā)生，及時發(fā)現(xiàn)死鎖并采取相應(yīng)的措施。

SHOW ENGINE INNODB STATUS 命令

SHOW ENGINE INNODB STATUS 命令可以獲取 InnoDB 存儲引擎的詳細狀態(tài)信息，包括死鎖的相關(guān)信息。通過這個命令，可以查看死鎖的原因、涉及的事務(wù)、被鎖住的行和死鎖的圖形化表現(xiàn)等。

示例：

SHOW ENGINE INNODB STATUS;

輸出中 LATEST DETECTED DEADLOCK 部分會包含關(guān)于死鎖的詳細信息，例如：

• 交易ID：參與死鎖的事務(wù) ID。
• 鎖定的表：涉及的表和行。
• 鎖定的類型：鎖的類型（如排他鎖、共享鎖）。
• 等待資源：死鎖過程中各個事務(wù)等待的資源。

死鎖信息存儲到日志文件

MySQL 可以配置記錄死鎖信息到錯誤日志中。你可以在 MySQL 配置文件中啟用這個功能，設(shè)置 innodb_status_output 和 innodb_status_output_locks 參數(shù)為 ON，這樣死鎖信息將會自動輸出到日志文件中。

配置示例：

[mysqld] innodb_status_output = ON innodb_status_output_locks = ON

使用 MySQL 的 Performance Schema

MySQL 的 Performance Schema 提供了一種更加詳細的方式來監(jiān)控死鎖。通過查詢 performance_schema.data_locks 表和 performance_schema.events_statements_history_long 表，可以獲取死鎖發(fā)生的歷史信息。

示例：

SELECT * FROM performance_schema.data_locks WHERE lock_status = 'LOCK WAIT';

8.2 死鎖的調(diào)試與分析

當(dāng)死鎖發(fā)生時，通過收集死鎖信息，可以幫助我們分析死鎖的原因，進而找到解決方案。以下是一些分析死鎖的關(guān)鍵步驟。

檢查死鎖的死鎖圖

死鎖圖顯示了死鎖中的事務(wù)和資源關(guān)系。通過死鎖圖，可以看到哪些事務(wù)相互等待，哪些資源被鎖定。理解這些圖形，能夠幫助分析事務(wù)之間的相互依賴和資源爭用，從而更清晰地知道如何優(yōu)化。死鎖圖可以通過 SHOW ENGINE INNODB STATUS 獲取，其中包括死鎖的具體情況。

例如：

LATEST DETECTED DEADLOCK
------------------------
2024-12-13 14:25:17 0x7f2e7fefb700
*** (1) TRANSACTION:
TRANSACTION 123456, ACTIVE 10 sec, process id 12345, thread id 123456789
LOCK WAIT, mode S
RECORD LOCKS space id 456 page no 123 n bits 72 index `PRIMARY` of table `test_db`.`test_table` trx id 123456 lock_mode S
*** (2) TRANSACTION:
TRANSACTION 789012, ACTIVE 5 sec, process id 78901, thread id 234567890
WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 456 page no 123 n bits 72 index `PRIMARY` of table `test_db`.`test_table` trx id 789012 lock_mode X

從上面的死鎖圖可以看到，事務(wù)1正在等待事務(wù)2的共享鎖，事務(wù)2正在等待事務(wù)1的排他鎖，從而導(dǎo)致了死鎖。

分析鎖等待和鎖順序

死鎖發(fā)生的原因通常與鎖的獲取順序不一致有關(guān)。在上面死鎖圖中的示例中，如果事務(wù)1和事務(wù)2按照相同的順序獲取鎖，死鎖就不會發(fā)生。因此，查看鎖的順序以及鎖等待鏈，能夠幫助分析死鎖發(fā)生的原因。

定位涉及的表和索引

死鎖中的表和索引是鎖定沖突的主要區(qū)域。在死鎖圖中，你可以看到哪些表和索引被鎖定。根據(jù)這些信息，你可以檢查表和索引的設(shè)計，是否有必要優(yōu)化索引或查詢，減少鎖的競爭。

確認死鎖的事務(wù)類型

死鎖通常發(fā)生在多個事務(wù)并發(fā)更新同一數(shù)據(jù)時。你可以分析這些事務(wù)，確認哪些操作可能導(dǎo)致鎖競爭。例如，頻繁的更新、刪除、插入操作可能導(dǎo)致死鎖的發(fā)生。

8.3 死鎖解決方案

在確認死鎖發(fā)生的原因后，下面是一些可能的解決方案：

調(diào)整事務(wù)順序

如果死鎖是由于事務(wù)按不同順序請求鎖導(dǎo)致的，可以通過調(diào)整事務(wù)的執(zhí)行順序來避免死鎖。例如，確保所有事務(wù)以相同的順序獲取鎖。

減少鎖粒度

將事務(wù)的鎖定范圍縮小，盡量避免全表掃描和長時間持有鎖的操作。例如，使用分頁查詢和批量更新，減少鎖定的記錄數(shù)。

使用適當(dāng)?shù)乃饕?/strong>