在開發或維護的過程中查詢數據庫的時候常常會遇到發生死鎖的問題，這里總結一些預防死鎖的規范。
1. 應盡可能縮短事務。在同一DB中並發執行多個需要長時間運行的事務時，發生死鎖的概率較大。事務運行時間越長，其持有排它鎖（exclusive鎖）或更新鎖（update鎖）的時間便越長，從而堵塞了其它活動並可能導致死鎖。保持事務在一個批處理中，可以最小化事務的網絡通信往返量，減少完成事務可能的延遲並釋放鎖。同時，涉及多個表的查詢更新操作，若比較耗時，盡量不要放在一個事務內處理，能分割便分割。若不能分割，便盡可能使之在業務量較小的時間(例如子夜或者午餐時間)執行。
2. 應按同一順序訪問數據對象。如果所有並發事務按同一順序訪問對象，則發生死鎖的可能性會降低。例如，如果兩個並發事務獲得 Supplier 表上的鎖，然后獲得Part表上的鎖，則在其中一個事務完成之前，另一個事務被阻塞在Supplier表上。第一個事務提交或回滾后，第二個事務繼續進行。不發生死鎖。將存儲過程用於所有的數據修改可以標准化訪問對象的順序。
3. 必須避免編寫包含用戶交互的事務。因為運行沒有用戶交互的批處理的速度要遠遠快於用戶手動響應查詢的速度，若用戶不能及時反饋，則此事務將掛起。因而將嚴重降低系統的吞吐量，因為事務持有的任何鎖只有在事務提交或回滾時才會釋放。即使不出現死鎖的情況，訪問同一資源的其它事務也會被阻塞，等待該事務完成。
4. 可使用低隔離級別。確定事務是否能在更低的隔離級別上運行。執行提交讀允許事務讀取另一個事務已讀取（未修改）的數據，而不必等待第一個事務完成。使用較低的隔離級別（例如提交讀）而不使用較高的隔離級別（例如可串行讀）可以縮短持有共享鎖的時間，從而降低了鎖定爭奪。
5. 可考慮體系結構的優化與代碼重構，提高系統整體的運行效率。例如盡可能不采用效率低下的計算模型，復雜的業務應采用異步任務調度處理。
6. 可通過程序控制事務提交的時機。如果一次檢索出了10萬條記錄但只更改了其中的100條，就可以通過代碼來執行100個update。或是用分段提交，即所有的修改使用多個事務進行提交，但這樣會使事務不完整，應酌情使用。
7. 宜將經常更新的數據庫和查詢數據庫分開。定期將不改變的數據導入查詢數據庫中，這樣查詢和更新就可以分開進行，而降低死鎖機率。
8. 在進行數據庫模式設計時，應注意外鍵引用的完整性，並對外鍵加索引。如果更新了父表的主鍵，由於外鍵上沒有索引，所以子表會被鎖定；如果刪除了父表中的一行，整個子表也會被鎖定。
"重要的不是治愈，而是帶着病痛活下去。"