當多個事務同時持有和請求同一資源上的鎖而產生循環依賴的時候就產生了死鎖。死鎖發生在事務試圖以不同的順序鎖定資源。以StockPrice表上的兩個事務為例：

事務1

事務 #2

如果不走運的話，每個事務都可以執行完第一個語句，并在過程中鎖住資源。然后每個事務都試圖去執行第二行語句，當時卻發現它被鎖住了。兩個事務將永遠的等待對方完成，除非有其他原因打斷死鎖。

為了解決這個問題，數據庫實現了各種死鎖探查和超時機制。像InnoDB這樣復雜的存儲引擎會提示循環依賴并且立即返回錯誤。否則死鎖將會導致查詢非常緩慢。其他一些不好的做法是等待超時后放棄。當前InnoDB處理死鎖的方式是回滾持有最少排他行級鎖的事務。（幾乎最簡單的回滾的參考指標）

鎖的行為是順序是存儲引擎決定的。因此，一些存儲引擎可能會在特定的操作順序下發生死鎖，其他的可能沒有。死鎖有兩種：一些是因為實際數據沖突而無法避免，一些是因為存儲引擎的工作方式產生。

只有部分或者完全回滾其中的一個事務才可能打破死鎖。死鎖是事務系統中客觀存在的事實，你的應該在設計上必須應該考慮處理死鎖。一些業務系統可以從頭重試事務。

如何處理死鎖
死鎖是事務型數據庫典型的問題，但是除非它們頻繁出現以至于你更本不能運行某個事務，它們一般是不危險的。正常地，你必須編寫你的應用程序使得它們總是準備如果因為死鎖而 回滾一個事務就重新發出一個事務。

InnoDB使用自動行級鎖定。即使在只插入或刪除單個行的事務的情況下，你可以遇到死鎖。這是因為這些操作不是真正的“極小的”，它們自動對插入或刪除的行的（可能是數個）索引記錄設置鎖定。

你可以用下列技術對付死鎖減少它們發生的可能性：

用Use SHOW INNODB STATUS來確定最后一個死鎖的原因。這樣可以幫助你調節應用程序來避免死鎖。

總是準備著重新發出事務，如果它因為死鎖而失敗了。死鎖不危險，再試一次。

經常提交你的事務。小事務更少地傾向于沖突。

如果你正使用鎖定讀，（SELECT ... FOR UPDATE或 ... LOCK IN SHARE MODE），試著用更低的隔離級別，比如READ COMMITTED。

以固定的順序訪問你的表和行。則事務形成良好定義的查詢并且沒有死鎖。