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

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

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

圖2.SQL Server通過阻塞來實現(xiàn)并發(fā)

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

使用sys.dm_tran_locks這個DMV

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

這里值得注意的是sys.dm_tran_locks這個DMV看到的是在查詢時間點的數(shù)據(jù)庫鎖的情況，并不包含任何歷史鎖的記錄?？梢岳斫鉃閿?shù)據(jù)庫在查詢時間點加鎖情況的快照。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所示。