資料庫和作業系統一樣，是乙個多使用者使用的共享資源。當多個使用者併發地訪問資料時，在資料庫中就會產生多個事務同時訪問同一資料的情況。若對併發操作不加控制就可能會讀取和儲存不正確的資料，破壞資料庫的一致性。加鎖是實現資料庫併發控制的乙個非常重要的技術。在實際應用中經常會遇到的與鎖相關的異常情況，當兩個事務需要一組有衝突的鎖，而不能將事務繼續下去的話，就會出現死鎖，嚴重影響應用的正常執行。
在資料庫中有兩種基本的鎖型別：排它鎖（exclusive locks，即x鎖）和共享鎖（share locks，即s鎖）。當資料物件被加上排它鎖時，其他的事務不能對它讀取和修改。加了共享鎖的資料物件可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖型別來對資料庫的事務進行併發控制。
下面總結下這兩種鎖造成的常見的死鎖情況與解決方案:
一. 事務之間對資源訪問順序的交替
出現原因：
乙個使用者a 訪問表a（鎖住了表a），然後又訪問表b；另乙個使用者b 訪問表b（鎖住了表b），然後企圖訪問表a；這時使用者a由於使用者b已經鎖住表b，它必須等待使用者b釋放表b才能繼續，同樣使用者b要等使用者a釋放表a才能繼續，這就死鎖就產生了。
解決方法：
這種死鎖比較常見，是由於程式的bug產生的，除了調整的程式的邏輯沒有其它的辦法。仔細分析程式的邏輯，對於資料庫的多表操作時，盡量按照相同的順序進行處理，盡量避免同時鎖定兩個資源，如操作a和b兩張表時，總是按先a後b的順序處理， 必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源。
二. 併發修改同一記錄
出現原因：
使用者a查詢一條紀錄，然後修改該條紀錄；這時使用者b修改該條紀錄，這時使用者a的事務裡鎖的性質由查詢的共享鎖企圖上公升到獨佔鎖，而使用者b裡的獨佔鎖由於a有共享鎖存在所以必須等a釋放掉共享鎖，而a由於b的獨佔鎖而無法上公升的獨佔鎖也就不可能釋放共享鎖，於是出現了死鎖。這種死鎖由於比較隱蔽，但在稍大點的專案中經常發生。
一般更新模式由乙個事務組成，此事務讀取記錄，獲取資源（頁或行）的共享 (s) 鎖，然後修改行，此操作要求鎖轉換為排它 (x) 鎖。如果兩個事務獲得了資源上的共享模式鎖，然後試圖同時更新資料，則乙個事務嘗試將鎖轉換為排它 (x) 鎖。共享模式到排它鎖的轉換必須等待一段時間，因為乙個事務的排它鎖與其它事務的共享模式鎖不相容；發生鎖等待。第二個事務試圖獲取排它 (x) 鎖以進行更新。由於兩個事務都要轉換為排它 (x) 鎖，並且每個事務都等待另乙個事務釋放共享模式鎖，因此發生死鎖。
解決方法：
a. 使用樂觀鎖進行控制。樂觀鎖大多是基於資料版本（version）記錄機制實現。即為資料增加乙個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加乙個「version」欄位來實現。讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。樂觀鎖機制避免了長事務中的資料庫加鎖開銷（使用者a和使用者b操作過程中，都沒有對資料庫資料加鎖），大大提公升了大併發量下的系統整體效能表現。hibernate 在其資料訪問引擎中內建了樂觀鎖實現。需要注意的是，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的使用者更新操作不受我們系統的控制，因此可能會造成髒資料被更新到資料庫中。
b. 使用悲觀鎖進行控制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，如oracle的select … for update語句，以保證操作最大程度的獨占性。但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。如乙個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進行修改時（如更改使用者賬戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對成百上千個併發，這樣的情況將導致災難性的後果。所以，採用悲觀鎖進行控制時一定要考慮清楚。
c. sqlserver可支援更新鎖
為解決死鎖，sqlserver引入更新鎖,它有如下特徵：
(1) 加鎖的條件：當乙個事務執行update語句時，資料庫系統會先為事務分配一把更新鎖。
(2) 解鎖的條件：當讀取資料完畢，執行更新操作時，會把更新鎖公升級為獨佔鎖。
(3) 與其他鎖的相容性：更新鎖與共享鎖是相容的，也就是說，乙個資源可以同時放置更新鎖和共享鎖，但是最多放置一把更新鎖。這樣，當多個事務更新相同的資料時，只有乙個事務能獲得更新鎖，然後再把更新鎖公升級為獨佔鎖，其他事務必須等到前乙個事務結束後，才能獲取得更新鎖，這就避免了死鎖。
(4) 併發效能：允許多個事務同時讀鎖定的資源，但不允許其他事務修改它。
例子如下:
t1:
begin tran
select * from
table(updlock) (加更新鎖)
update
table
set column1='hello'
t2:begin tran
select * from
table(updlock)
update
table
set column1='world'
t1執行select，加更新鎖。
t2執行，準備加更新鎖，但發現已經有乙個更新鎖在那兒了，只好等。
當後來有user3、user4…需要查詢table表中的資料時，並不會因為t1的select在執行就被阻塞，照樣能查詢,提高了效率。
三. 索引不當導致全表掃瞄
出現原因：
如果在事務中執行了一條不滿足條件的語句，執行全表掃瞄，把行級鎖上公升為表級鎖，多個這樣的事務執行後，就很容易產生死鎖和阻塞。類似的情況還有當表中的資料量非常龐大而索引建的過少或不合適的時候，使得經常發生全表掃瞄，最終應用系統會越來越慢，最終發生阻塞或死鎖。
解決方法：
sql語句中不要使用太複雜的關聯多表的查詢；使用「執行計畫」對sql語句進行分析，對於有全表掃瞄的sql語句，建立相應的索引進行優化。
資料庫常見死鎖原因及處理
資料庫是乙個多使用者使用的共享資源，當多個使用者併發地訪問資料時，在資料庫中就會產生多個事務同時訪問同一資料的情況。若對併發操作不加控制就可能會讀取和儲存不正確的資料，破壞資料庫的一致性。加鎖是實現資料庫併發控制的乙個非常重要的技術。在實際應用中經常會遇到的與鎖相關的異常情況，當兩個事務需要一組有衝...
資料庫常見死鎖原因及處理
資料庫是乙個多使用者使用的共享資源，當多個使用者併發地訪問資料時，在資料庫中就會產生多個事務同時訪問同一資料的情況。若對併發操作不加控制就可能會讀取和儲存不正確的資料，破壞資料庫的一致性。加鎖是實現資料庫併發控制的乙個非常重要的技術。在實際應用中經常會遇到的與鎖相關的異常情況，當兩個事務需要一組有衝...
資料庫死鎖處理
查詢 select ses.sid as sid,ses.serial as serial num,ses.process as process,ses.username as db username,pro.spid as host pid,ses.machine as machine,subst...