死鎖

死鎖是指兩個或多個事務相互持有和請求相同資源上的鎖，產生了循環依賴。當多個事務試圖以不同的順序鎖定資源時會導致死鎖。當多個事務鎖定相同的資源時，也可能會發生死鎖。例如，設想運行下面兩個針對主鍵為（stock_id，date）的StockPrice表的事務：

事務1

事務2

每個事務都開始執行第一個查詢，在處理過程中會更新一行數據，同時在主鍵索引和其他唯一索引中將該行鎖定。然后，每個事務將在第二個查詢中嘗試更新第二行數據，卻發現該行已經被鎖定。這兩個事務將永遠等待對方完成，除非有其他因素介入解除死鎖。我們將在第7章進一步介紹索引如何隨著模式的發展而影響或破壞查詢的性能。

為了解決這個問題，數據庫系統實現了各種死鎖檢測和鎖超時機制。更復雜的系統，比如InnoDB存儲引擎，檢測到循環依賴后會立即返回一個錯誤信息。這可能是一件好事——否則，死鎖將表現為非常緩慢的查詢。還有一種方式，當超過鎖等待超時的時間限制后直接終止查詢，這樣做通常來說不太好。InnoDB目前處理死鎖的方式是將持有最少行級排他鎖的事務回滾（這是一種最容易回滾的近似算法）。

鎖的行為和順序是和存儲引擎相關的。同樣的一系列查詢語句，有些存儲引擎會產生死鎖，有些則不會。死鎖的產生有雙重原因：有些是因為真正的數據沖突，這種情況通常很難避免，但有些則完全是由于存儲引擎的實現方式導致的。[8]

一旦發生死鎖，如果不回滾其中一個事務（部分或全部），就無法打破死鎖。對于事務型的系統，這是無法避免的，所以應用程序在設計時必須考慮如何處理死鎖。大多數情況下只需要重新從頭開始執行被回滾的事務即可，除非又遇到另一個死鎖。