其實所有的死鎖最深層的原因就是一個:資源競爭
表現一:
一個用戶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 ....