事務 A 獲取了行 1 的***享鎖。
事務 B 獲取了行 2 的***享鎖。
現在，事務 A 請求行 2 的排他鎖，但在事務 B 完成並釋放其對行 2 持有的***享鎖之前被阻塞。
現在，事務 B 請求行 1 的排他鎖，但在事務 A 完成並釋放其對行 1 持有的***享鎖之前被阻塞。
事務 A 必須在事務 B 完成之後才能完成，但事務 B 被事務 A 阻塞。這種情況也稱為循環依賴關系：事務 A 依賴於事務 B，而事務 B 又依賴於事務 A，從而形成了壹個循環。
除非某個外部進程斷開死鎖，否則死鎖中的兩個事務都將無限期等待下去。Microsoft SQL Server Database Engine 死鎖監視器定期檢查陷入死鎖的任務。如果監視器檢測到循環依賴關系，將選擇其中壹個任務作為犧牲品，然後終止其事務並提示錯誤。這樣，其他任務就可以完成其事務。對於事務以錯誤終止的應用程序，它還可以重試該事務，但通常要等到與它壹起陷入死鎖的其他事務完成後執行。
在應用程序中使用特定編碼約定可以減少應用程序導致死鎖的機會。有關詳細信息，請參閱將死鎖減至最少。
死鎖經常與正常阻塞混淆。事務請求被其他事務鎖定的資源的鎖時，發出請求的事務壹直等到該鎖被釋放。默認情況下，SQL Server 事務不會超時（除非設置了 LOCK_TIMEOUT）。因為發出請求的事務未執行任何操作來阻塞擁有鎖的事務，所以該事務是被阻塞，而不是陷入了死鎖。最後，擁有鎖的事務將完成並釋放鎖，然後發出請求底事務將獲取鎖並繼續執行。
死鎖有時稱為抱死。
不只是關系數據庫管理系統，任何多線程系統上都會發生死鎖，並且對於數據庫對象的鎖之外的資源也會發生死鎖。例如，多線程操作系統中的壹個線程要獲取壹個或多個資源（例如，內存塊）。如果要獲取的資源當前為另壹線程所擁有，則第壹個線程可能必須等待擁有線程釋放目標資源。這就是說，對於該特定資源，等待線程依賴於擁有線程。在數據庫引擎 實例中，當獲取非數據庫資源（例如，內存或線程）時，會話會死鎖。
在上圖中，對於 Part 表鎖資源，事務 T1 依賴於事務 T2。同樣，對於 Supplier 表鎖資源，事務 T2 依賴於事務 T1。因為這些依賴關系形成了壹個循環，所以在事務 T1 和事務 T2 之間存在死鎖。