形成數據庫表死鎖的緣由分析及解決方案

在聯機事務處理(OLTP)的數據庫應用系統中，多用戶、多任務的併發性是系統最重要的技術指標之一。爲了提升併發性，目前大部分RDBMS都採用加鎖技術。然而因爲現實環境的複雜性，使用加鎖技術又不可避免地產生了死鎖問題。所以如何合理有效地使用加鎖技術，最小化死鎖是開發聯機事務處理系統的關鍵。           
1、死鎖產生的緣由           
    在聯機事務處理系統中，形成死機主要有兩方面緣由。一方面，因爲多用戶、多任務的併發性和事務的完整性要求，當多個事務處理對多個資源同時訪問時，若雙方已鎖定一部分資源但也都須要對方已鎖定的資源時，沒法在有限的時間內徹底得到所需的資源，就會處於無限的等待狀態，從而形成其對資源需求的死鎖。           
    另外一方面，數據庫自己加鎖機制的實現方法不一樣，各數據庫系統也會產生其特殊的死鎖狀況。如在Sybase       SQL Server 11中，最小鎖爲2K一頁的加鎖方法，而非行級鎖。若是某張表的記錄數少且記錄的長度較短(即記錄密度高，如應用系統中的系統配置表或系統參數表就屬於此類表)，被訪問的頻率高，就容易在該頁上產生死鎖。
         
2、容易發生死鎖的幾種狀況以下:           
一、不一樣的存儲過程、觸發器、動態SQL語句段按照不一樣的順序同時訪問多張表;               
二、在交換期間添加記錄頻繁的表，但在該表上使用了非羣集索引(non-clustered);               
三、表中的記錄少，且單條記錄較短，被訪問的頻率較高；           
四、整張表被訪問的頻率高(如代碼對照表的查詢等)。           

3、以上死鎖狀況的對應解決方案       

一、在系統實現時應規定全部存儲過程、觸發器、動態SQL語句段中，對多張表的操做老是使用同一順序。如：

    有兩個存儲過程proc一、proc2，都須要訪問三張表zltab、z2tab和z3tab，若是proc1按照zltab、z2tab和z3tab的順序進行訪問，那麼，proc2也應該按照以上順序訪問這三張表。           

二、對在交換期間添加記錄頻繁的表，使用羣集索引(clustered)，以減小多個用戶添加記錄到該表的最後一頁上，在表尾產生熱點，形成死鎖。這類表多爲往來帳的流水錶，其特色是在交換期間須要在表尾追加大量的記錄，而且對已添加的記錄不作或較少作刪除操做。           

三、對單張表中記錄數不太多，且在交換期間select或updata較頻繁的表可以使用設置每頁最大行的辦法，減小數據在表中存放的密度，模擬行級鎖，減小在該表上死鎖狀況的發生。這類表多爲信息繁雜且記錄條數少的表。如：

系統配置表或系統參數表。在定義該表時添加以下語句：    with   max_rows_per_page=1           

四、在存儲過程、觸發器、動態SQL語句段中，若對某些整張表select操做較頻繁，則可能在該表上與其餘訪問該表的用戶產生死鎖。對於檢查帳號是否存在， 但被檢查的字段在檢查期間不會被更新等非關鍵語句，能夠採用在select命令中使用at  isolation read   uncommitted子句的方法解決。該方法實際上下降了select語句對整張表的鎖級別，提升了其餘用戶對該表操做的併發性。在系統高負荷運行時，該方法的效果尤其顯著。           

如：select * from titles at isolation read uncommitted           

    對流水號一類的順序數生成器字段，能夠先執行updata流水號字段+1，而後再執行select獲取流水號的方法進行操做。