死鎖發生時，數據庫系統會自動回滾一個事務以解除僵局，用戶可通過show engine innodb status;診斷死鎖原因，并在必要時通過kill命令終止問題進程；根本解決方法包括：1.保持事務短小，減少鎖持有時間；2.統一資源訪問順序，避免交叉等待；3.為查詢添加合適索引，減少鎖定范圍；4.使用低隔離級別降低鎖沖突；5.優化sql避免全表掃描；6.使用顯式鎖控制并發；7.應用程序實現重試機制應對死鎖；這些措施能有效預防死鎖，提升數據庫性能與數據一致性。
數據庫死鎖，在使用phpMyAdmin操作時確實是個讓人頭疼的問題，它通常不是PHPMyAdmin本身的問題，而是數據庫層面的并發控制機制在特定操作順序下的一種表現。簡單來說，就是兩個或多個事務互相等待對方釋放資源，導致誰也無法繼續執行，最終數據庫系統會選擇一個“犧牲品”事務進行回滾，來打破僵局。
解決這類問題，核心在于識別死鎖發生的原因，然后采取措施避免它再次出現。
解決方案
當死鎖發生時，首先要做的就是診斷。在mysql/mariadb中，SHOW ENGINE INNODB STATUS; 是你的第一手資料。你會在輸出中找到一個 LATEST DETECTED DEADLOCK 的部分，這里詳細記錄了哪個事務是“犧牲品”（victim），哪些鎖被請求，以及哪個事務持有了這些鎖。通過分析這些信息，你可以大致判斷是哪兩條sql語句在互相“較勁”。
立即學習“PHP免費學習筆記（深入）”；
PHPMyAdmin本身并沒有直接的“解決死鎖”按鈕，因為死鎖發生在數據庫引擎層面。如果你發現有死鎖發生，并且需要手動干預（比如一個長時間運行的查詢導致了問題），你可以通過PHPMyAdmin的“SQL”選項卡執行 SHOW PROCESSLIST; 來查看當前所有正在運行的進程。找到那個導致問題的進程ID（通常是正在等待或長時間運行的查詢），然后執行 KILL [進程ID]; 來終止它。但這是一種緊急措施，務必謹慎，因為它會中斷正在進行的事務。
更根本的解決方案，是理解并優化你的數據庫操作。很多時候，死鎖的發生是因為并發操作時，事務獲取鎖的順序不一致，或者事務持續時間過長，持有過多不必要的鎖。
為什么在使用PHPMyAdmin操作數據庫時會發生死鎖？
我覺得，這事兒跟PHPMyAdmin關系不大，它只是一個方便我們與數據庫交互的工具。死鎖的根本原因在于數據庫的并發控制機制和我們操作數據庫的方式。想象一下，你和同事同時去拿兩本書，你先拿了A再想拿B，他先拿了B再想拿A，結果就是誰也拿不到第二本，都卡住了。數據庫死鎖也是這個道理。
具體來說，可能的原因有很多：
- 并發更新同一批數據，但順序不同。 這是最常見的場景。比如，事務A更新了表X的行1，然后想更新表Y的行1；事務B更新了表Y的行1，然后想更新表X的行1。它們就陷入了互相等待的境地。
- 缺少必要的索引。 如果查詢沒有合適的索引，數據庫可能需要掃描更多的行甚至整張表，這會鎖定更多的資源，大大增加死鎖的幾率。比如，一個簡單的 UPDATE 語句，如果 WHERE 條件沒有被索引覆蓋，可能就會導致全表鎖或大量的行鎖。
- 事務持續時間過長。 如果一個事務開啟后，執行了大量的操作，并且長時間不提交或回滾，它就會一直持有大量的鎖，阻塞其他事務的進行，從而增加死鎖的風險。
- 不恰當的事務隔離級別。 雖然InnoDB的默認隔離級別 REPEATABLE READ 在多數情況下表現良好，但在某些高并發場景下，它可能比 READ COMMITTED 持有更長時間的共享鎖，從而增加死鎖的可能性。但改動隔離級別需要非常謹慎，因為它會影響數據一致性。
- 復雜查詢和隱式鎖。 有些復雜的 JOIN、子查詢或者 INSERT … select 等操作，在執行過程中可能會隱式地獲取大量的鎖，而且這些鎖的獲取順序可能難以預測，增加了死鎖的概率。
如何有效預防數據庫死鎖的發生？
預防死鎖，說到底就是優化你的數據庫操作策略。這需要從多個層面去考慮，不僅僅是寫SQL那么簡單。
- 保持事務盡可能短小。 事務越短，持有鎖的時間就越短，與其他事務沖突的可能性就越低。盡量避免在事務中包含用戶交互、網絡請求等耗時操作。
- 統一資源訪問順序。 如果你的應用需要同時訪問多張表或多行數據，盡量確保所有事務都以相同的順序訪問這些資源。比如，總是先更新表A，再更新表B。這能大大減少死鎖的發生。
- 為查詢添加合適的索引。 這是最基礎也是最重要的優化手段之一。良好的索引能夠讓數據庫快速定位到需要操作的行，減少掃描范圍，從而減少需要鎖定的資源量。特別是那些在 WHERE 子句、JOIN 條件和 ORDER BY 中經常出現的列，都應該考慮建立索引。
- 使用低隔離級別（如果業務允許）。 比如將事務隔離級別從默認的 REPEATABLE READ 調整為 READ COMMITTED。在 READ COMMITTED 下，事務只在當前語句執行期間持有行鎖，語句執行完畢后立即釋放，可以有效減少鎖沖突。但請注意，這可能會引入“不可重復讀”的問題，需要評估業務場景是否能接受。
- 優化SQL語句，避免全表掃描。 確保你的 UPDATE 和 delete 語句能夠通過索引快速定位到目標行。避免在 WHERE 子句中使用函數或者對列進行運算，這會導致索引失效。
- 使用 for UPDATE 或 LOCK IN SHARE MODE 明確鎖定。 在某些需要嚴格控制并發的場景，你可以通過 SELECT … FOR UPDATE 來顯式地鎖定一行或多行，確保在事務提交前，其他事務不能修改這些行。這是一種悲觀鎖，雖然會增加鎖等待，但可以避免死鎖，并且保證數據一致性。
- 考慮應用程序層面的重試機制。 即使做了很多優化，死鎖也無法100%避免。當死鎖發生時，數據庫會回滾其中一個事務。你的應用程序應該能夠捕獲到這個錯誤（例如SQLSTATE 40001或錯誤碼1213），并嘗試重新執行被回滾的事務。
死鎖對數據庫性能和數據一致性有哪些影響？
死鎖這東西，雖然數據庫系統會自己處理（通過回滾一個事務來解除），但它對數據庫的整體運行和數據處理流程還是有不少負面影響的。
-
性能下降：
- 資源浪費： 被回滾的事務，它之前所做的一切工作都白費了，包括CPU計算、I/O操作等等，這些都是資源的浪費。
- 事務重試： 如果應用程序有重試機制，那么被回滾的事務需要重新執行，這又會消耗額外的資源和時間，增加了整體的響應延遲。
- 連鎖反應： 一個死鎖可能導致其他事務長時間等待，從而引發一系列的性能問題，比如連接池耗盡、隊列堆積等。
- 吞吐量降低： 頻繁的死鎖和回滾會顯著降低數據庫每秒能處理的事務數量。
-
數據一致性（間接影響）：
- 邏輯中斷： 盡管數據庫系統通過回滾確保了物理層面的數據一致性（即數據不會出現損壞或部分更新），但從業務邏輯層面看，一個事務的突然回滾可能導致業務流程中斷。比如，一個訂單創建流程中途被回滾，用戶可能會看到錯誤信息，或者需要重新下單。
- 應用程序復雜性： 為了處理死鎖，應用程序需要實現復雜的錯誤處理和重試邏輯，這增加了代碼的復雜度和維護成本。如果處理不當，可能導致數據不一致的風險（例如，一個操作在數據庫層面回滾了，但應用層面卻認為成功了）。
- 用戶體驗受損： 用戶可能會遇到操作失敗、響應緩慢或者需要重復提交的情況，這無疑會降低用戶對系統的滿意度。
總的來說，死鎖雖然是數據庫并發控制的正常產物，但它的頻繁出現通常是數據庫設計或應用邏輯存在缺陷的信號。持續的監控和優化是避免其負面影響的關鍵。
