共計 1400 個字符，預計需要花費 4 分鐘才能閱讀完成。

本篇內容主要講解“Mysql 兩階段鎖和死鎖是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Mysql 兩階段鎖和死鎖是什么”吧!

兩階段鎖

概念

講的是 InnoDB 如何處理行鎖的上鎖，釋放鎖的行為。

在事務使用過程中，對記錄以主鍵為條件刪改時，會立刻加上排他鎖，這完成了上鎖階段。

當刪改動作完成后，這個鎖并不會立即釋放，需要等至事務提交時，才會釋放鎖。

引發的問題 - 阻塞事務 A 事務 Bbegin;
update t set k=k+1 where id=1;
update t set k=k+1 where id=2;

begin;
update t set k=k+2 where id=1;commit;

根據兩階段鎖協議，事務 B 將會因為 id= 1 的數據被事務 A 上了鎖，而阻塞，因為事務 B 需要拿到鎖后才能進行下一步操作。

上述這個問題，可能看似問題不大，但是如果不止是事務 B，還有事務 C，事務 D，等等很多，做的是跟事務 B 一樣的事，問題就大了，被阻塞的線程就會多了起來。

如何處理上述問題

我們應該盡量將可能會引起阻塞的語句，放到事務的最后面操作，例如上述事務 A 例子中的 id= 1 的語句，它和第二句的執行并沒有什么關聯關系，可是它是容易引起阻塞的語句，因為在事務 B 中也要對這一行數據做鎖操作（在各類事務中頻繁使用的，如公司的收付款賬號余額記錄，即 ** 熱點行 **），但是卻在事務一開始就拿到鎖了。

本質上，是縮短了拿鎖時間和釋放鎖之間的時間。即持有鎖的時間縮短，以此減少鎖引起的阻塞。

死鎖

概念

兩個線程，互相在等待對方釋放資源。

在兩個事務 A，B 中。

事務 A 拿到了資源 A 的鎖。

事務 B 拿到了資源 B 的鎖。

事務 A 去拿資源 B 的鎖。

事務 B 去拿資源 A 的鎖。

很明顯，步驟 3，4 中，事務 A，B 都想去拿鎖，但是又都拿不到，因為對方都還沒有釋放該資源的鎖。這種現象就是死鎖。

引發的問題 - 死鎖

在 InnoDB 中，有一個拿鎖的等待時間配置，超過這個時間就會拋出異常，這個時間默認是 50 秒。通常來說，有一個接口需要 50 秒后才響應是不可接受的。innodb_lock_wait_timeout。

那是不是把這個配置時間設置短一點就行了？比如 1 秒？

應該是不可以的，因為可能會影響到你的正常業務，或許你的業務導致你的事務執行時間本身就比較長，超過 1 秒。超出這個時間會拋出異常，你的正常業務就被影響了。

那該如何處理上述問題

在 InnoDB 中，還有一個自動檢測死鎖并處理的配置。它是默認開啟的，在極端情況下，雖然能處理問題，但是對 CPU 消耗特別大。

它原理是在事務中即將要上鎖的時候，會去檢測其他并發線程，有沒有將此資源鎖住，如果檢測到某個線程 A 有，然后再會去檢測線程 A 的依賴有沒有被其他并發線程鎖住，如此循環往復，最終判斷這些鎖會不會形成死鎖。

可以看出，線程越多，檢測成本就越大。innodb_deadlock_detect。

僅代表個人當前的學習做出的對此問題的處理和總結：

1. 關閉死鎖檢測，將拿鎖時間配置縮短至預估的最高時間，通常不會超過 15 秒，超過 15 秒后，需要有重試機制。

2. 開啟死鎖檢測，在應用層控制并發連接數，使用連接池控制 Mysql 的連接數，在服務層限制 Mysql 最大連接數。

到此，相信大家對“Mysql 兩階段鎖和死鎖是什么”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！