增加Index來解決Deadlock的案例

 

  最近在解決一個資料庫死結的問題，按說資料庫死結依靠強大的資料庫自身的探查功能很容易找到發生位置從而進行分析解決。 但是最近遇到一個很奇怪的死結案例，通過 –T 1222的switch，獲得了死結發生時候的SQL調用代碼，和死結資源情況發現造成死結的雙方都宣稱獲得了同一個資源的X鎖，並且還要請求U鎖，最終相互等待。經過一番探索發現這個等待的資源是表上的Cluster Index。 雙方都獲得了不同page上的x鎖，而請求其他page上的U鎖，而不是table層級的，所以在SQLServer，我就誤以為兩個session在等待同一個資源。

  最終的原因是，一個Update語句之後的where子句沒有用任何index的欄位進行檢索，這樣SQLServer就進行table scan檢索所有資料以找到符合要求的row，方法就是在目標行上加U鎖，然後檢查是否需要更新，如果需要就升級成X鎖，否則釋放U鎖，看。這樣低效的操作遇到大的並發執行時候很容易相互死結，這樣問題就發生了。

 

 

解決辦法嘛，就是改寫where子句，或者建立index以保證所有查詢的column都有index這樣，sqlserver就不會進行table scan而是進行index的查詢然後直接定位需要更新的目標行，U鎖-〉X鎖-〉釋放X鎖。