MySQL InnoDB 存儲引擎鎖機制全面教程：從行鎖到死鎖處理

鎖類型對比

InnoDB 核心鎖類型

• 共享鎖（S Lock）：允許事務讀取一行數據（SELECT ... LOCK IN SHARE MODE）。
• 排他鎖（X Lock）：允許事務更新/刪除一行數據（SELECT ... FOR UPDATE、UPDATE、DELETE）。

兼容性矩陣：S 與 S 兼容，S 與 X、X 與 X 均互斥。

一致性非鎖定讀（MVCC）

InnoDB 通過 多版本並發控制 (MVCC) 實現：讀取操作不等待行鎖釋放，而是讀取數據的快照版本（由 Undo Log 構建）。

• READ COMMITTED：總是讀取行的最新提交版本。
• REPEATABLE READ (默認)：總是讀取事務開始時的數據快照。

非鎖定讀極大提升並發性，但在以下場景會隱式加鎖：

1. 顯式鎖定讀：SELECT ... FOR UPDATE、LOCK IN SHARE MODE。
2. 外鍵檢查：插入/更新子表時需掃描父表，自動加 S 鎖。

InnoDB 鎖算法

1. Record Lock：鎖定單條索引記錄。
2. Gap Lock：鎖定索引間隙（不含記錄本身），防止幻讀。
3. Next-Key Lock：Gap Lock + Record Lock，鎖定範圍及記錄本身（RR 隔離級別默認算法）。

若表無顯式索引，InnoDB 使用隱式主鍵加鎖。

鎖引發的經典問題

1. 丟失更新

解決：對讀取記錄加排他鎖，將並發操作串行化。

2. 髒讀

讀到未提交數據，僅發生於 READ UNCOMMITTED 級別。

3. 不可重復讀

同一事務兩次讀取同一行數據不一致（被其他事務修改提交）。InnoDB 通過 Next-Key Lock 避免。

4. 幻讀

同一查詢條件下，重新讀取發現新增滿足條件的行。RR 級別下 Next-Key Lock 可解決大部分幻讀。

死鎖深度解析

發生四大必要條件

1. 互斥條件
2. 請求與保持條件
3. 不剝奪條件
4. 循環等待條件

InnoDB 死鎖檢測機制

• 滿足循環等待時觸發。
• 鎖結構超過配置最大數量或遍歷深度超限時（性能保護機制）也判定為死鎖。

常見四種死鎖形式：雙表交叉鎖、同表主鍵索引沖突、主鍵與非聚簇索引沖突、鎖升級導致等待隊列阻塞。

死鎖避免最佳實踐

1. 大量 INSERT ... SELECT 改用 SELECT INTO OUTFILE + LOAD DATA INFILE。
2. 事務操作集盡量精簡，減少持鎖時間。
3. WHERE 條件統一使用主鍵或索引，避免混用導致鎖順序不一致。
4. 減少 SQL 嵌套層級，拆分複雜查詢。
5. 定時任務錯峰執行，避免同表大事務並發。
6. 應用層捕獲死錯異常（Error 1213），自動重試事務。

死鎖排查與解決步驟

1. SHOW PROCESSLIST 找到阻塞線程 ID，KILL 掉。
2. SHOW ENGINE INNODB STATUS 查看最近死鎖詳情（持有鎖、等待鎖、SQL 文本）。
3. 查詢 information_schema.innodb_trx、innodb_locks、innodb_lock_waits 表分析當前事務與鎖等待鏈。