在SQL Server中，每一個查詢都會找到最短路徑實現自己的目標。如果數據庫只接受一個連接一次只執行一個查詢。那么查詢當然是要多快好省的完成工作。但對于大多數數據庫來說是需要同時處理多個查詢的。這些查詢并不會像紳士那樣排隊等待執行，而是會找最短的路徑執行。因此，就像十字路口需要一個紅綠燈那樣，SQL Server也需要一個紅綠燈來告訴查詢:什么時候走，什么時候不可以走。這個紅綠燈就是鎖。

圖1.查詢可不會像紳士們那樣按照次序進行排隊

在開始談鎖之前，首先要簡單了解一下事務和事務的ACID屬性。如果你了解了事務之間的影響方式，你就應該知道在數據庫中，理論上所有的事務之間應該是完全隔離的。但是實際上，要實現完全隔離的成本實在是太高(必須是序列化的隔離等級才能完全隔離，這個并發性有點….)。所以，SQL Server默認的Read Commited是一個比較不錯的在隔離和并發之間取得平衡的選擇。SQL Server通過鎖，就像十字路口的紅綠燈那樣，告訴所有并發的連接，在同一時刻上，那些資源可以讀取，那些資源可以修改。前面說到，查詢本身可不是什么紳士，所以需要被監管。當一個事務需要訪問的資源加了其所不兼容的鎖，SQL Server會阻塞當前的事務來達成所謂的隔離性。直到其所請求資源上的鎖被釋放，如圖2所示。

圖2.SQL Server通過阻塞來實現并發

了解SQL Server在某一時間點上的加鎖情況無疑是學習鎖和診斷數據庫死鎖和性能的有效手段。我們最常用的查看數據庫鎖的手段不外乎兩種:

使用sys.dm_tran_locks這個DMV

SQL Server提供了sys.dm_tran_locks這個DMV來查看當前數據庫中的鎖,前面的圖2就是通過這個DMV來查看的.

這里值得注意的是sys.dm_tran_locks這個DMV看到的是在查詢時間點的數據庫鎖的情況，并不包含任何歷史鎖的記錄。可以理解為數據庫在查詢時間點加鎖情況的快照。sys.dm_tran_locks所包含的信息分為兩類，以resource為開頭的描述鎖所在的資源的信息，另一類以request開頭的信息描述申請的鎖本身的信息。如圖3所示。更詳細的說明可以查看MSDN(http://msdn.microsoft.com/en-us/library/ms190345.aspx)

圖3.sys.dm_tran_locks

  這個DMV包含的信息比較多，所以通常情況下，我們都會寫一些語句來從這個DMV中提取我們所需要的信息。如圖4所示。