SQL Server死鎖產生原因及解決辦法
其實所有的死鎖最深層的原因就是一個：資源競爭
表現一：
一個使用者A 訪問表A(鎖住了表A)，然後又訪問表B，另一個使用者B 訪問表B(鎖住了表B)，然後企圖訪問表A，這時使用者A由於使用者B已經鎖住表B，它必須等待使用者B釋放表B，才能繼續，好了他老人家就只好老老實實在這等了，同樣使用者B要等使用者A釋放表A才能繼續這就死鎖了。
解決方法：
這種死鎖是由於你的程式的BUG產生的，除了調整你的程式的邏輯別無他法
仔細分析你程式的邏輯：
1：儘量避免同時鎖定兩個資源
2: 必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源.
表現二：
使用者A讀一條紀錄，然後修改該條紀錄。這是使用者B修改該條紀錄，這裡使用者A的事務裡鎖的性質由共享鎖企圖上升到獨佔鎖(for update),而使用者B裡的獨佔鎖由於A有共享鎖存在所以必須等A釋放掉共享鎖，而A由於B的獨佔鎖而無法上升的獨佔鎖也就不可能釋放共享鎖，於是出現了死鎖。
這種死鎖比較隱蔽，但其實在稍大點的專案中經常發生。
解決方法：
讓使用者A的事務（即先讀後寫型別的操作),在select 時就是用Update lock
語法如下：
select * from table1 with(updlock) where ....
--------------------------------------------------------------------------------接上面文章，繼續探討資料庫死鎖問題
死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個物件，導致雙方互相等待。簡單的例子如下：
trans1 trans2
------------------------------------------------------------------------------------------------
1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction
2.update table A 2.update table B
3.update table B
4.IDBConnection.Commit 4.IDBConnection.Commit
那麼，很容易看到，如果trans1和trans2，分別到達了step3，那麼trans1會請求對於B的X鎖，trans2會請求對於A的X鎖，而二者的鎖在step2上已經被對方分別持有了。由於得不到鎖，後面的Commit無法執行，這樣雙方開始死鎖。
好，我們看一個簡單的例子，來解釋一下，應該如何解決死鎖問題。
-- Batch #1
CREATE DATABASE deadlocktest
GO
USE deadlocktest
SET NOCOUNT ON
DBCC TRACEON (1222, -1)
-- 在SQL2005中，增加了一個新的dbcc引數，就是1222，原來在2000下，我們知道，可以執行dbcc
-- traceon(1204,3605,-1)看到所有的死鎖資訊。SqlServer 2005中，對於1204進行了增強，這就是1222。
GO
IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1
IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1
IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2
GO
CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))
GO
DECLARE @x int
SET @x = 1
WHILE (@x <= 1000) BEGIN
INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)
SET @x = @x + 1
END
GO
CREATE CLUSTERED INDEX cidx ON t1 (c1)
CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)
GO
CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
上述sql建立一個deadlock的示範資料庫，插入了1000條資料，並在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外建立了兩個sp，分別是從t1中select資料和update資料。
好，開啟一個新的查詢視窗，我們開始執行下面的query：
-- Batch #2
USE deadlocktest
SET NOCOUNT ON
WHILE (1=1) EXEC p2 4
GO
開始執行後，然後我們開啟第三個查詢視窗，執行下面的query：
-- Batch #3
USE deadlocktest
SET NOCOUNT ON
CREATE TABLE #t1 (c2 int, c3 int)
GO
WHILE (1=1) BEGIN
INSERT INTO #t1 EXEC p1 4
TRUNCATE TABLE #t1
END
GO
開始執行，哈哈，很快，我們看到了這樣的錯誤資訊：
Msg 1205, Level 13, State 51, Procedure p1, Line 4
Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
spid54發現了死鎖。
那麼，我們該如何解決它？
在SqlServer 2005中，我們可以這麼做：
1.在trans3的視窗中，選擇EXEC p1 4，然後right click，看到了選單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。
2.注意右面的視窗中，wordload有三個選擇：負載檔案、表、查詢語句，因為我們選擇了查詢語句的方式，所以就不需要修改這個radio option了。
3.點左上角的Start Analysis按鈕
4.抽根菸，回來後看結果吧！出現了一個分析結果視窗，其中，在Index Recommendations中，我們發現了一條資訊：大意是，在表t1上增加一個非聚集索引索引：t2+t1。
5.在當前視窗的上方選單上，選擇Action選單，選擇Apply Recommendations，系統會自動建立這個索引。
重新執行batch #3，呵呵，死鎖沒有了。
為什麼會死鎖呢？再回顧一下兩個sp的寫法：
CREATE PROC p1 @p1 int AS
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
GO
CREATE PROC p2 @p1 int AS
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1
GO
很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1裡面updata A，update B；trans2裡面upate B，update A，根本不貼邊啊！
那麼，什麼導致了死鎖？
需要從事件日誌中，看sql的死鎖資訊：
Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”):
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”):
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.
The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.
首先，我們看看p1的執行計劃。怎麼看呢？可以執行set statistics profile on，這句就可以了。下面是p1的執行計劃
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))
|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] >= [@p1] AND [t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)
我們看到了一個nested loops，第一行，利用索引t1.c2來進行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查詢整行的資料。這是什麼？就是bookmark lookup啊！為什麼？因為我們需要的c2、c3不能完全的被索引t1.c1帶出來，所以需要書籤查詢。
好，我們接著看p2的執行計劃。
UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1
|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))
|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))
|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...
|--Top(ROWCOUNT est 0)
|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)
通過聚集索引的seek找到了一行，然後開始更新。這裡注意的是，update的時候，它會申請一個針對clustered index的X鎖的。
實際上到這裡，我們就明白了為什麼update會對select產生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖！）select裡面最後的那個clustered index seek。死鎖的另一半在哪裡呢？注意我們的select語句，c2存在於索引idx1中，c1是一個聚集索引cidx。問題就在這裡！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪裡？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。
SO………，問題就這樣被發現了。
總結一下，就是說，某個query使用非聚集索引來select資料，那麼它會在非聚集索引上持有一個S鎖。當有一些select的列不在該索引上，它需要根據rowid找到對應的聚集索引的那行，然後找到其他資料。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因為正在修改的某個列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的資訊，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發生鳥。
那麼，為什麼我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之後的執行計劃：
SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1
|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] >= [@p1] AND [deadlocktest].[dbo].[t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)
哦，對於clustered index的需求沒有了，因為增加的覆蓋索引已經足夠把所有的資訊都select出來。就這麼簡單。
實際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那麼會出現一個死鎖的圖，很直觀的說。
下面的方法，有助於將死鎖減至最少（詳細情況，請看SQLServer聯機幫助，搜尋：將死鎖減至最少即可。
. 按同一順序訪問物件。
. 避免事務中的使用者互動。
. 保持事務簡短並處於一個批處理中。
. 使用較低的隔離級別。
. 使用基於行版本控制的隔離級別。
. 將 READ_COMMITTED_SNAPSHOT 資料庫選項設定為 ON，使得已提交讀事務使用行版本控制。
. 使用快照隔離。
. 使用繫結連線。
作者：freedk
一、深入淺出理解索引結構 實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。下面，我們舉例來說明一下聚集索引和非聚集索引的區別：
其實，我們的漢語字典的正文字身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的，那麼“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最後部分，因為“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。
如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據“偏旁部首”查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字並不是真正的分別位於“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的對映。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。
通過以上例子，我們可以理解到什麼是“聚集索引”和“非聚集索引”。進一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序。 二、何時使用聚集索引或非聚集索引 下面的表總結了何時使用聚集索引或非聚集索引（很重要）：
| 動作描述 | 使用聚集索引 | 使用非聚集索引 |
| 列經常被分組排序 | 應 | 應 |
| 返回某範圍內的資料 | 應 | 不應 |
| 一個或極少不同值 | 不應 | 不應 |
| 小數目的不同值 | 應 | 不應 |
| 大數目的不同值 | 不應 | 應 |
| 頻繁更新的列 | 不應 | 應 |
| 外來鍵列 | 應 | 應 |
| 主鍵列 | 應 | 應 |
| 頻繁修改索引列 | 不應 | 應 |
這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER預設是在主鍵上建立聚集索引的。
通常，我們會在每個表中都建立一個ID列，以區分每條資料，並且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的例項中的列Gid就是如此。此時，如果我們將這個列設為主鍵，SQL SERVER會將此列預設為聚集索引。這樣做有好處，就是可以讓您的資料在資料庫中按照ID進行物理排序，但筆者認為這樣做意義不大。
顯而易見，聚集索引的優勢是很明顯的，而每個表中只能有一個聚集索引的規則，這使得聚集索引變得更加珍貴。
從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢範圍，避免全表掃描。在實際應用中，因為ID號是自動生成的，我們並不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個ID號都不同的欄位作為聚集索引也不符合“大數目的不同值情況下不應建立聚合索引”規則；當然，這種情況只是針對使用者經常修改記錄內容，特別是索引項的時候會負作用，但對於查詢速度並沒有影響。
在辦公自動化系統中，無論是系統首頁顯示的需要使用者簽收的檔案、會議還是使用者進行檔案查詢等任何情況下進行資料查詢都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。
通常，辦公自動化的首頁會顯示每個使用者尚未簽收的檔案或會議。雖然我們的where語句可以僅僅限制當前使用者尚未簽收的情況，但如果您的系統已建立了很長時間，並且資料量很大，那麼，每次每個使用者開啟首頁的時候都進行一次全表掃描，這樣做意義是不大的，絕大多數的使用者1個月前的檔案都已經瀏覽過了，這樣做只能徒增資料庫的開銷而已。事實上，我們完全可以讓使用者開啟系統首頁時，資料庫僅僅查詢這個使用者近3個月來未閱覽的檔案，通過“日期”這個欄位來限制表掃描，提高查詢速度。如果您的辦公自動化系統已經建立的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。
在這裡之所以提到“理論上”三字，是因為如果您的聚集索引還是盲目地建在ID這個主鍵上時，您的查詢速度是沒有這麼高的，即使您在“日期”這個欄位上建立的索引（非聚合索引）。下面我們就來看一下在1000萬條資料量的情況下各種查詢的速度表現（3個月內的資料為25萬條）： （1）僅在主鍵上建立聚集索引，並且不劃分時間段： Select gid,fariqi,neibuyonghu,title from tgongwen 用時：128470毫秒（即：128秒） （2）在主鍵上建立聚集索引，在fariq上建立非聚集索引： select gid,fariqi,neibuyonghu,title from Tgongwen
where fariqi> dateadd(day,-90,getdate()) 用時：53763毫秒（54秒） （3）將聚合索引建立在日期列（fariqi）上： select gid,fariqi,neibuyonghu,title from Tgongwen
where fariqi> dateadd(day,-90,getdate()) 用時：2423毫秒（2秒） 雖然每條語句提取出來的都是25萬條資料，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時的差異。事實上，如果您的資料庫真的有1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網頁上的表現就是超時，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個最重要的因素。得出以上速度的方法是：在各個select語句前加： declare @d datetime
set @d=getdate() 並在select語句後加： select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate()) 2、只要建立索引就能顯著提高查詢速度
事實上，我們可以發現上面的例子中，第2、3條語句完全相同，且建立索引的欄位也相同；不同的僅是前者在fariqi欄位上建立的是非聚合索引，後者在此欄位上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，並非是在任何欄位上簡單地建立索引就能提高查詢速度。
從建表的語句中，我們可以看到這個有著1000萬資料的表中fariqi欄位有5003個不同記錄。在此欄位上建立聚合索引是再合適不過了。在現實中，我們每天都會發幾個檔案，這幾個檔案的發文日期就相同，這完全符合建立聚集索引要求的：“既不能絕大多數都相同，又不能只有極少數相同”的規則。由此看來，我們建立“適當”的聚合索引對於我們提高查詢速度是非常重要的。 3、把所有需要提高查詢速度的欄位都加進聚集索引，以提高查詢速度
上面已經談到：在進行資料查詢時都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。既然這兩個欄位都是如此的重要，我們可以把他們合併起來，建立一個複合索引（compound index）。
很多人認為只要把任何欄位加進聚集索引，就能提高查詢速度，也有人感到迷惑：如果把複合的聚集索引欄位分開查詢，那麼查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結果集都是25萬條資料）：（日期列fariqi首先排在複合聚集索引的起始列，使用者名稱neibuyonghu排在後列）： （1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5'' 查詢速度：2513毫秒 （2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5'' and neibuyonghu=''辦公室'' 查詢速度：2516毫秒 （3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=''辦公室'' 查詢速度：60280毫秒 從以上試驗中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到複合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的複合索引列還要略快（在查詢結果集數目一樣的情況下）；而如果僅用複合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當然，語句1、2的查詢速度一樣是因為查詢的條目數一樣，如果複合索引的所有列都用上，而且查詢結果少的話，這樣就會形成“索引覆蓋”，因而效能可以達到最優。同時，請記住：無論您是否經常使用聚合索引的其他列，但其前導列一定要是使用最頻繁的列。 四、其他書上沒有的索引使用經驗總結 1、用聚合索引比用不是聚合索引的主鍵速度快
下面是例項語句：（都是提取25萬條資料） select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''使用時間：3326毫秒 select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000使用時間：4470毫秒 這裡，用聚合索引比用不是聚合索引的主鍵速度快了近1/4。 2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小資料量情況下 select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi用時：12936 select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid用時：18843 這裡，用聚合索引比用一般的主鍵作order by時，速度快了3/10。事實上，如果資料量很小的話，用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多；而資料量如果很大的話，如10萬以上，則二者的速度差別不明顯。 3、使用聚合索引內的時間段，搜尋時間會按資料佔整個資料表的百分比成比例減少，而無論聚合索引使用了多少個： select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-1-1''用時：6343毫秒（提取100萬條） select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-6-6''用時：3170毫秒（提取50萬條） select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''用時：3326毫秒（和上句的結果一模一樣。如果採集的數量一樣，那麼用大於號和等於號是一樣的） select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi>''2004-1-1'' and fariqi<''2004-6-6''用時：3280毫秒 4、日期列不會因為有分秒的輸入而減慢查詢速度
下面的例子中，共有100萬條資料，2004年1月1日以後的資料有50萬條，但只有兩個不同的日期，日期精確到日；之前有資料50萬條，有5000個不同的日期，日期精確到秒。 select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi>''2004-1-1'' order by fariqi用時：6390毫秒 select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi<''2004-1-1'' order by fariqi用時：6453毫秒 五、其他注意事項 “水可載舟，亦可覆舟”，索引也一樣。索引有助於提高檢索效能，但過多或不當的索引也會導致系統低效。因為使用者在表中每加進一個索引，資料庫就要做更多的工作。過多的索引甚至會導致索引碎片。
所以說，我們要建立一個“適當”的索引體系，特別是對聚合索引的建立，更應精益求精，以使您的資料庫能得到高效能的發揮。
當然，在實踐中，作為一個盡職的資料庫管理員，您還要多測試一些方案，找出哪種方案效率最高、最為有效。 感覺筆者講比較透徹，並參考了另一篇：索引的使用和優化
思想基本一致的，總結下來，對日期建立聚集索引比較合適。