死鎖的概念

死鎖：死鎖一般是事務相互等待對方資源，最後形成環路造成的。

對於死鎖，資料庫處理方法：犧牲一個連線，保證另外一個連線成功執行。

發生死鎖會返回ERROR：1213 錯誤提示，大部分的死鎖InnoDB儲存引擎本身可以偵測到，不需要人為進行干預。

注意：

InnoDB儲存引擎並不會回滾大部分的錯誤異常，像阻塞章節裡面的例子，但是死鎖例外，發現死鎖後，InnoDB儲存引擎會馬上回滾一個事務，會返回1213錯誤。

死鎖的情形舉例

eg1：

mysql死鎖以及死鎖日誌分析

mysql死鎖以及死鎖日誌分析

mysql死鎖以及死鎖日誌分析

分析死鎖日誌：

第一部分

從日誌裡我們可以看到事務1當前正在執行update info_users set mobile="18514656666" where mobile="18514656620"，該條語句正在申請表info_users的索引IDX_MOBILE的X鎖，所以提示lock_mode X waiting

第二部分：

然後日誌的下半部分說明了事務2當前‘持有的鎖’以及‘等待的鎖’：

從日誌的HOLDS THE LOCKS(S)塊中我們可以看到事務2持有索引IDX_MOBILE的X鎖，並且是記錄鎖（Record Lock）。該鎖是透過事務2在步驟2執行的update語句申請的。

從日誌的WAITING FOR THIS LOCK TO BE GRANTED塊中我們可以看到事務2正在申請持有表info_area的索引GEN_CLUST_INDEX的X鎖，該鎖是delete from info_area where id=1;語句申請的。

eg2：

mysql死鎖以及死鎖日誌分析

eg3：

mysql死鎖以及死鎖日誌分析

mysql死鎖以及死鎖日誌分析

mysql死鎖以及死鎖日誌分析

分析死鎖日誌：

第一部分

從日誌裡我們可以看到事務1當前正在執行DELETE from users where uid="bbb";，該條語句正在申請索引UID的X鎖，所以提示lock_mode X waiting

第二部分：

然後日誌的下半部分說明了事務2當前‘持有的鎖’以及‘等待的鎖’：

從日誌的HOLDS THE LOCKS(S)塊中我們可以看到事務2持有索引UID的X鎖，並且是記錄鎖（Record Lock）。該鎖是透過事務2在步驟2執行的delete語句申請的。

從日誌的WAITING FOR THIS LOCK TO BE GRANTED塊中我們可以看到事務2正在申請持有索引UID的S鎖，該鎖是insert INTO users VALUES(2,"bbb");語句申請的。insert語句在普通情況下是會申請X鎖，但是這裡出現了S鎖。這是因為uid欄位是一個索引，所以insert語句會在插入前進行一次duplicate key的檢查，為了使這次檢查成功，需要申請S鎖防止其他事務對uid欄位進行修改。

那麼為什麼該S鎖會失敗呢？這是對同一個欄位的鎖的申請是需要排隊的。S鎖前面還有一個未申請成功的X鎖，所以S鎖必須等待，所以形成了迴圈等待，死鎖出現了。

透過閱讀死鎖日誌，我們可以清楚地知道兩個事務形成了怎樣的迴圈等待，再加以分析，就可以逆向推斷出迴圈等待的成因，也就是死鎖形成的原因。