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

圖1.查詢可不會像紳士們那樣按照次序進(jìn)行排隊(duì)

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

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

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

使用sys.dm_tran_locks這個DMV

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

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

圖3.sys.dm_tran_locks

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