資料庫在進行insert，update，delete這些更新操作的時候為了保證資料一致性都會使用排他鎖。
乙個事務裡進行update操作，在事務結束之前（commit or rollback）排他鎖不會被釋放。因此在乙個事務裡update多條資料的時候執行順序就尤為重要，兩個併發事務中更新操作的執行順序不同就有可能產生死鎖：（x, y分別表示一行資料）
transaction a finally finally }
另外，如果執行的update操作不在事務裡，但乙個update操作更新了多行資料（ex: update .. set .. where id > 1），在大併發的情況下也會有死鎖的風險，原因仍然是與更新資料行的順序有關。因此還是推薦更新操作最好以主鍵作為條件最為嚴謹，否則就需要在程式中先對更新的資料進行排序再進行批量更新(ex: update .. set .. where id in (1, 2, 3, 4..))。
當然如果是讀寫鎖，要考慮讀寫的頻率。
資料庫死鎖
1.死鎖的概念 死鎖是程序死鎖的簡稱，是由dijkstra於1965年研究銀行家演算法時首先提出來的。它是計算機作業系統乃至併發程式設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。我們先看看這樣乙個生活中的例子 在一條河上有一座橋，橋面較窄，只能容納一...
資料庫死鎖
死鎖 所謂死鎖 是指兩個或兩個以上的程序在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等待的程序稱為死鎖程序 由於資源占用是互斥的，當某個程序提出申請資源後，使得有關程序在無外力協助下，永遠分配不到必需的...
資料庫死鎖
如果需要 修改 一條資料，首先資料庫管理系統會在上面加鎖，以保證在同一時間只有乙個事務能進行修改操作。鎖定 locking 發生在當乙個事務獲得對某一資源的 鎖 時，這時，其他的事務就不能更改這個資源了，這種機制的存在是為了保證資料一致性。每個使用 關係型資料庫的程式都可能遇到資料死鎖 1 的情況。...