數據庫鎖表及阻塞的緣由和解決辦法

問題說明

當多個用戶併發地存取數據時，在數據庫中就會產生多個事務同時存取同一數據的狀況。若對併發操做不加控制就可能會讀取和存儲不正確的數據，破壞數據庫的一致性。加鎖是實現數據庫併發控制的一個很是重要的技術。在實際應用中常常會遇到的與鎖 相關的異常狀況，當兩個事務須要一組有衝突的鎖，而不能將事務繼續下去的話，就會出現死鎖，嚴重影響應用的正常執行。 
在數據庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當數據對象被加上排它鎖時，其餘的事務不能對它讀取和修改。加了共享鎖的數據對象能夠被其餘事務讀取，但不能修改。數據庫利用這兩 種基本的鎖類型來對數據庫的事務進行併發控制。 
關於共享鎖和排他鎖總結: 
1mysql InnoDB引擎默認的修改數據語句，update,delete,insert都會自動給涉及到的數據加上排他鎖，select語句默認不會加任何鎖類型 
2排他鎖不能和其餘鎖共存 
3共享鎖能夠和其餘鎖共存(因爲排他鎖的特性,共享鎖只能和共享鎖共存) 

死鎖的第一種狀況

一個用戶A 訪問表A(鎖住了表A),而後又訪問表B；另外一個用戶B 訪問表B(鎖住了表B)，而後企圖訪問表A；這時用戶A因爲用戶B已經鎖住表B，它必須等待用戶B釋放表B才能繼續，一樣用戶B要等用戶A釋放表A才能繼續，這就死鎖就產生了。

解決方法

這種死鎖比較常見，是因爲程序的BUG產生的，除了調整的程序的邏輯沒有其它的辦法。仔細分析程序的邏輯，對於數據庫的多表操做時， 儘可能按照相同的順序進行處理，儘可能避免同時鎖定兩個資源，如操做A和B兩張表時，老是按先A後B的順序處理， 必須同時鎖定兩個資源時，要保證在任什麼時候刻都應該按照相同的順序來鎖定資源。

---

死鎖的第二種狀況

用戶A查詢一條紀錄，而後修改該條紀錄；這時用戶B修改該條紀錄，這時用戶A的事務裏鎖的性質由查詢的共享鎖企圖上升到獨佔鎖，而用戶B裏的獨佔鎖因爲A有共享鎖存在因此必須等A釋放掉共享鎖，而A因爲B的獨佔鎖而沒法上升的獨佔鎖也就不可能釋放共享鎖，因而出現了死鎖。這種死鎖比較隱蔽，但在稍大點的項目中常常發生。如在某項目中，頁面上的按鈕點擊後，沒有使按鈕馬上失效，使得用戶會屢次快速點擊同一按鈕，這樣同一段代碼對數據庫同 一條記錄進行屢次操做，很容易就出現這種死鎖的狀況。

解決方法

一、對於按鈕等控件，點擊後使其馬上失效，不讓用戶重複點擊，避免對同時對同一條記錄操做。 
二、使用樂觀鎖進行控制。樂觀鎖大可能是基於數據版本（Version）記錄機制實現。即爲數據增長一個版本標識，在基於數據庫表的版本解決 方案中，通常是經過爲數據庫表增長一個「version」字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據 的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。樂觀鎖機制避免了 長事務中的數據庫加鎖開銷（用戶A和用戶B操做過程當中，都沒有對數據庫數據加鎖），大大提高了大併發量下的系統總體性能表現。hibernate 在其數據訪問引擎中內置了樂觀鎖實現。須要注意的是，因爲樂觀鎖機制是在咱們的系統中實現，來自外部系統的用戶更新操做不受咱們系統的控制，所以可能會造 成髒數據被更新到數據庫中。

---

死鎖的第三種狀況

若是在事務中執行了一條不知足條件的update語句，則執行全表掃描，把行級鎖上升爲表級鎖，多個這樣的事務執行後，就很容易產生死鎖和阻塞。相似的狀況還有當表中的數據量很是龐大而索引建的過少或不合適的時候，使得常常發生全表掃描，最終應用系統會愈來愈慢，最終發生阻塞或死鎖。

解決方法

SQL語句中不要使用太複雜的關聯多表的查詢；使用「執行計劃」對SQL語句進行分析，對於有全表掃描的SQL語句，創建相應的索引進行優化。