數據庫死鎖預防規範

在開發或維護的過程當中查詢數據庫的時候經常會遇到發生死鎖的問題，這裏總結一些預防死鎖的規範。

1. 應儘量縮短事務。在同一DB中併發執行多個須要長時間運行的事務時，發生死鎖的機率較大。事務運行時間越長，其持有排它鎖（exclusive鎖）或更新鎖（update鎖）的時間便越長，從而堵塞了其它活動並可能致使死鎖。保持事務在一個批處理中，能夠最小化事務的網絡通訊往返量，減小完成事務可能的延遲並釋放鎖。同時，涉及多個表的查詢更新操做，若比較耗時，儘可能不要放在一個事務內處理，能分割便分割。若不能分割，便儘量使之在業務量較小的時間(例如子夜或者午飯時間)執行。

2. 應按同一順序訪問數據對象。若是全部併發事務按同一順序訪問對象，則發生死鎖的可能性會下降。例如，若是兩個併發事務得到 Supplier 表上的鎖，而後得到Part表上的鎖，則在其中一個事務完成以前，另外一個事務被阻塞在Supplier表上。第一個事務提交或回滾後，第二個事務繼續進行。不發生死鎖。將存儲過程用於全部的數據修改能夠標準化訪問對象的順序。

3. 必須避免編寫包含用戶交互的事務。由於運行沒有用戶交互的批處理的速度要遠遠快於用戶手動響應查詢的速度，若用戶不能及時反饋，則此事務將掛起。於是將嚴重下降系統的吞吐量，由於事務持有的任何鎖只有在事務提交或回滾時纔會釋放。即便不出現死鎖的狀況，訪問同一資源的其它事務也會被阻塞，等待該事務完成。

4. 可以使用低隔離級別。肯定事務是否能在更低的隔離級別上運行。執行提交讀容許事務讀取另外一個事務已讀取（未修改）的數據，而沒必要等待第一個事務完成。使用較低的隔離級別（例如提交讀）而不使用較高的隔離級別（例如可串行讀）能夠縮短持有共享鎖的時間，從而下降了鎖定爭奪。

5. 可考慮體系結構的優化與代碼重構，提升系統總體的運行效率。例如儘量不採用效率低下的計算模型，複雜的業務應採用異步任務調度處理。

6. 可經過程序控制事務提交的時機。若是一次檢索出了10萬條記錄但只更改了其中的100條，就能夠經過代碼來執行100個update。或是用分段提交，即全部的修改使用多個事務進行提交，但這樣會使事務不完整，應酌情使用。

7. 宜將常常更新的數據庫和查詢數據庫分開。按期將不改變的數據導入查詢數據庫中，這樣查詢和更新就能夠分開進行，而下降死鎖機率。

8. 在進行數據庫模式設計時，應注意外鍵引用的完整性，並對外鍵加索引。若是更新了父表的主鍵，因爲外鍵上沒有索引，因此子表會被鎖定；若是刪除了父表中的一行，整個子表也會被鎖定。

 

"重要的不是治癒，而是帶着病痛活下去。"