其實所有的死鎖最深層的原因就是一個:資源競争
表現一:
一個使用者A 通路表A(鎖住了表A),然後又通路表B
另一個使用者B 通路表B(鎖住了表B),然後企圖通路表A
這時使用者A由于使用者B已經鎖住表B，它必須等待使用者B釋放表B,才能繼續，好了他老人家就隻好老老實實在這等了
同樣使用者B要等使用者A釋放表A才能繼續這就死鎖了
解決方法：
這種死鎖是由于你的程式的BUG産生的，除了調整你的程式的邏輯别無他法
仔細分析你程式的邏輯，
1：盡量避免同時鎖定兩個資源
2: 必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源.
表現二:
使用者A讀一條紀錄，然後修改該條紀錄
這是使用者B修改該條紀錄
這裡使用者A的事務裡鎖的性質由共享鎖企圖上升到獨占鎖(for update),而使用者B裡的獨占鎖由于A有共享鎖存在是以必須等A釋
放掉共享鎖，而A由于B的獨占鎖而無法上升的獨占鎖也就不可能釋放共享鎖，于是出現了死鎖。
這種死鎖比較隐蔽，但其實在稍大點的項目中經常發生。
解決方法:
讓使用者A的事務（即先讀後寫類型的操作),在select 時就是用Update lock
文法如下：
select * from table1 with(updlock) where ....
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10294527/viewspace-122730/，如需轉載，請注明出處，否則将追究法律責任。
轉載于:http://blog.itpub.net/10294527/viewspace-122730/