官方定義如下：兩個事務都持有對方需要的鎖，並且在等待對方釋放，並且雙方都不會釋放自己的鎖。
這個就好比你有乙個人質，對方有乙個人質，你們倆去談判說換人。你讓對面放人，對面讓你放人。
看到這裡，也許你會有這樣的疑問，事務和談判不一樣，為什麼事務不能使用完鎖之後立馬釋放呢？居然還要操作完了之後一直持有鎖？這就涉及到 mysql 的併發控制了。
mysql的併發控制有兩種方式，乙個是 mvcc，乙個是兩階段鎖協議。那麼為什麼要併發控制呢？是因為多個使用者同時操作 mysql 的時候，為了提高併發效能並且要求如同多個使用者的請求過來之後如同序列執行的一樣（可序列化排程）。具體的併發控制這裡不再展開。咱們繼續深入討論兩階段鎖協議。
官方定義：
兩階段鎖協議是指所有事務必須分兩個階段對資料加鎖和解鎖，在對任何資料進行讀、寫操作之前，事務首先要獲得對該資料的封鎖；在釋放乙個封鎖之後，事務不再申請和獲得任何其他封鎖。對應到 mysql 上分為兩個階段：
擴充套件階段（事務開始後，commit 之前）：獲取鎖
收縮階段（commit 之後）：釋放鎖
就是說呢，只有遵循兩段鎖協議，才能實現可序列化排程。
但是兩階段鎖協議不要求事務必須一次將所有需要使用的資料加鎖，並且在加鎖階段沒有順序要求，所以這種併發控制方式會形成死鎖。
mysql有兩種死鎖處理方式：
等待，直到超時（innodb_lock_wait_timeout=50s）。
發起死鎖檢測，主動回滾一條事務，讓其他事務繼續執行（innodb_deadlock_detect=on）。
由於效能原因，一般都是使用死鎖檢測來進行處理死鎖。
死鎖檢測的原理是構建乙個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環，存在即有死鎖。
檢測到死鎖之後，選擇插入更新或者刪除的行數最少的事務回滾，基於 information_schema.innodb_trx 表中的 trx_weight 欄位來判斷。
利用命令show engine innodb status檢視死鎖原因。
除錯階段開啟 innodb_print_all_deadlocks，收集所有死鎖日誌。
使用事務，不使用lock tables。
保證沒有長事務。
操作完之後立即提交事務，特別是在互動式命令列中。
如果在用(select ... for update or select ... lock in share mode)，嘗試降低隔離級別。
修改多個表或者多個行的時候，將修改的順序保持一致。
建立索引，可以使建立的鎖更少。
最好不要用(select ... for update or select ... lock in share mode)。
如果上述都無法解決問題，那麼嘗試使用lock tables t1, t2, t3鎖多張表
mysql處理死鎖 mysql如何處理死鎖問題
mysql有兩種死鎖處理方式 1 等待，直到超時 innodb lock wait timeout 50s 2 發起死鎖檢測，主動回滾一條事務，讓其他事務繼續執行 innodb deadlock detect on 由於效能原因，一般都是使用死鎖檢測來進行處理死鎖。死鎖檢測 死鎖檢測的原理是構建乙個...
如何處理死鎖問題
總結如下 1.評估一下程式，看看是否確實需要有兩個mutex？如果只有乙個mutex，就不存在死鎖的問題了。2.避免在鎖住mutex的同時，去呼叫另外的我們不熟悉的函式，因為有可能這個函式包含了另外的鎖，所以我們必須清楚我們所呼叫的其他的函式或者類。3.如果確實需要在同一時間使用兩個以上的mutex...
SQL Server裡如何處理死鎖
在今天的文章裡，我想談下sql server裡如何處理死鎖。當2個查詢彼此等待時會發生死鎖，沒有乙個查詢可以繼續它們的操作。首先我想給你大致講下sql server如何處理死鎖。最後我會展示下sql sever裡特定的死鎖型別，還有你如何避免和解決它們。死鎖的好處是sql server自動檢測並解決...