我將分別從以下幾個方面進行講解mysql 死鎖 的每一個案例，希望能夠對你們有幫忙及啟發
-
pre --- 預備知識（可直接跳過，建議耐着性子看完）
-
鎖類型
-
一致性非鎖定讀
-
一致性鎖定讀
-
行鎖的三種算法
-
start --- 正式開始
-
死鎖的條件
-
死鎖分析
-
死鎖示例
pre
一、鎖類型 innodb存儲引擎實現了如下兩種標准的行級鎖（多粒度鎖定之意向鎖自行了解，此處拋出而已）
-
-
共享鎖（S Lock），允許事務讀一行數據。
-
排他鎖（X Lock），允許事務刪除或更新一行數據
-
二、一致性非鎖定讀
一致性的非鎖定讀是指InnoDB存儲引擎通過行多版本控制（MVCC自行了解）的方式來讀取當前執行時間數據庫中行的數據，而不需要等待訪問的行上X鎖的釋放。（在InnoDB存儲引擎的默認設置下，這是默認的讀取方式）
PS：1.該技術不會有額外的開銷，因為讀取的快照數據其實是行數據之前的版本數據，該實現是通過undo （undo log 事務回滾 自行了解）段來完成。
2.不同的事務隔離級別下，讀取的方式不同（並不是在每個事務隔離級別下都是采用非鎖定的一致性讀，自行思考，tip：臟讀，不可重復讀，幻讀）
三、一致性鎖定讀
-
-
SELECT...FOR UPDATE 對讀取的行記錄加一個X鎖，其他事務不能對已鎖定的行加上任何鎖
-
SELECT...LOCK IN SHARE MODE 對讀取的行記錄加一個S鎖，其他事務可以向被鎖定的行加S鎖，但如果加X鎖，則會被阻塞
-
(PS:以上要想使用必須在事務中，當事務提交了，鎖也就釋放了)
四、行鎖的三種算法
-
-
Record Lock: 單個行記錄上的鎖
-
Gap Lock: 間隙鎖，鎖定一個范圍，但不包含記錄本身
-
Next-Key Lock: Gap Lock + Record Lock，鎖定一個范圍，並且鎖定記錄本身 (可解決 Phantom Problem)
-
(PS:當查詢的索引含有唯一屬性時，InnoDB存儲引擎會對Next-Key Lock進行優化，將其降級為Record Lock，即鎖住索引本身，而不是范圍)
比較懶，上圖（分享過的圖）
