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

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

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

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

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

使用sys.dm_tran_locks這個(gè)DMV

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

這里值得注意的是sys.dm_tran_locks這個(gè)DMV看到的是在查詢時(shí)間點(diǎn)的數(shù)據(jù)庫鎖的情況，并不包含任何歷史鎖的記錄。可以理解為數(shù)據(jù)庫在查詢時(shí)間點(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

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