在查詢一中執(zhí)行更新操作：
BEGIN?TRAN
UPDATE?dbo.tb?SET?c2?=?'xx'?WHERE?c1?=?2;
WAITFOR?DELAY?'00:00:30';
UPDATE?dbo.tb?SET?c2?=?'xx'?WHERE?c1?=?5;
ROLLBACK;
在查詢一執(zhí)行開(kāi)始后，馬上在查詢二中執(zhí)行下面的操作
BEGIN?TRAN
UPDATE?dbo.tb?SET?c2?=?'xx'?WHERE?c1?=?1;
ROLLBACK;
形成死鎖模软，但是查詢二如果條件改為 c1 = 4 則不會(huì)死鎖缓窜。
開(kāi)始的時(shí)候想得比較簡(jiǎn)單，死鎖的表現(xiàn)是形成循環(huán)等待(對(duì)于兩個(gè)查詢而言，可以簡(jiǎn)單地認(rèn)為就是在相互等待對(duì)方鎖定資源的釋放)。
對(duì)于這個(gè)例子而言，第一個(gè)查詢更新兩次扁藕，會(huì)先更新并鎖定一條記錄，然后等待第二個(gè)更新球匕；但第二個(gè)查詢只會(huì)更新一條記錄纹磺，它要么與第一個(gè)查詢沖突，無(wú)法獲得鎖亮曹，需要等待查詢一完成，這個(gè)時(shí)候它并沒(méi)有鎖定什么秘症；要么能夠獲得鎖照卦，完成更新。似乎不應(yīng)該會(huì)出現(xiàn)死鎖乡摹，死鎖會(huì)不會(huì)是其他原因?qū)е隆?/p>
在自己的電腦上簡(jiǎn)單測(cè)試了一下役耕，似乎也確實(shí)沒(méi)有死鎖。
?但后面通過(guò)Profile跟蹤更新操作的下鎖情況才發(fā)現(xiàn)聪廉，自己的分析大錯(cuò)特錯(cuò)了瞬痘。主要原因在于沒(méi)有正確理解更新操作是如何用鎖的故慈。
?在聯(lián)機(jī)幫助上“鎖模式”中有關(guān)于更新的U（更新鎖）和X（排它鎖）的說(shuō)明
http://msdn.microsoft.com/zh-cn/library/ms175519(v=sql.105).aspx
不過(guò)說(shuō)得確實(shí)挺模糊的，里面還提到了S鎖框全，我一直以為是查詢數(shù)據(jù)過(guò)程中用的S鎖（也 SELECT 一樣）察绷，找到滿足條件的記錄后用U鎖，再轉(zhuǎn)換為X鎖做更新津辩。
?Profile（事件探查器）跟蹤的結(jié)果讓我知道了這是一個(gè)錯(cuò)誤的理解拆撼，在Profile中新建一個(gè)跟蹤，選擇Locks中的Lock:Acquired?(加鎖)喘沿，Lock:Released（釋放鎖）這兩個(gè)事件闸度，在篩選中設(shè)置只跟蹤測(cè)試用的查詢窗口對(duì)應(yīng)的spid（可以執(zhí)行?PRINT?@@SPID?獲得），然后執(zhí)行一個(gè)更新語(yǔ)句蚜印，比如?UPDATE?dbo.tb?SET?c2?=?'xx'?WHERE?c1?=?3
在Profile中可以看到莺禁，對(duì)于每條記錄都有加?U?鎖的操作，對(duì)于不滿足條件的記錄窄赋，會(huì)馬上釋放U鎖哟冬；對(duì)于滿足條件的記錄，最終轉(zhuǎn)換為X鎖寝凌。如下圖所示柒傻。
注意一下，在這個(gè)跟蹤結(jié)果里面较木，并沒(méi)有出現(xiàn)S鎖红符。
另外學(xué)做了一些測(cè)試:
通過(guò)加大記錄量做更新測(cè)試，會(huì)發(fā)現(xiàn)數(shù)據(jù)掃描涉及的記錄都有U鎖伐债，并不限于更新記錄所在的頁(yè)预侯。這從另一個(gè)角度說(shuō)明了大表中Scan?可怕。
當(dāng)使用索引Scan的時(shí)候峰锁，也會(huì)通過(guò)跟蹤發(fā)現(xiàn)所Scan的索引資源有U鎖萎馅，如果更新不涉及索引變化，那以只會(huì)對(duì)應(yīng)的記錄有U轉(zhuǎn)X鎖虹蒋，索引的U鎖會(huì)釋放糜芳；如果影響索引，那么索引的U鎖會(huì)轉(zhuǎn)X鎖魄衅。
刪除操作與更新操作類似
使用?UPDATE?aSET?c2?=?'xx'?FROM?dbo.tb?AS?a?WITH(NOLOCK)?WHERE?c1?=?3??的加鎖情況是一樣的峭竣， 并不會(huì)因?yàn)镹OLOCK的提示而不加U?或者?X?鎖
最后回頭研究一下示例中的死鎖問(wèn)題：
對(duì)于查詢一，第一個(gè)更新依次掃描表中所有記錄晃虫，對(duì)于每條記錄皆撩，加?U?鎖，判斷是否符合更新條件哲银，如果符合扛吞，轉(zhuǎn)換為?X?鎖呻惕；如果不符合條件，釋放?U?鎖滥比。第一個(gè)更新完成的時(shí)候亚脆，查詢一鎖定了一條記錄(由于事務(wù)未完成，所以鎖一直保持)守呜，然后等待第二個(gè)更新
對(duì)于查詢二型酥，依次掃描表中的每條記錄（與前面的更新一樣），如果它更新的記錄在查詢一更新的記錄前被掃描到查乒，那么這條記錄也會(huì)變成?X?鎖弥喉；當(dāng)繼續(xù)并進(jìn)行到查詢一的X鎖記錄的零點(diǎn)，U?與?X?沖突玛迄，無(wú)法繼續(xù)由境，這時(shí)候查詢二等待查詢一釋放鎖
查詢一的第二個(gè)更新開(kāi)始執(zhí)行，依次掃描每條記錄蓖议，同一個(gè)事務(wù)內(nèi)不會(huì)有沖突虏杰，所以它不會(huì)與自己之前鎖定的記錄有沖突，但進(jìn)行到查詢二鎖定的記錄的時(shí)候勒虾，它也無(wú)法獲得?U?鎖纺阔，它需要等待查詢二釋放資源。這個(gè)時(shí)候就形成了相互等待修然，符合死鎖條件
如果查詢二需要更新的記錄在查詢一的第一個(gè)更新記錄之后笛钝，則不會(huì)有死鎖，因?yàn)椴樵兌趻呙璧讲樵円坏谝粋€(gè)更新的記錄時(shí)就會(huì)因?yàn)殒i沖突等待了愕宋，這個(gè)時(shí)候它沒(méi)有對(duì)任何記錄設(shè)置與查詢一的操作有沖突的鎖玻靡。我自己測(cè)試的時(shí)候沒(méi)有死鎖，就是這種情況中贝。
注意這里面提到的順序囤捻，是數(shù)據(jù)讀取的順序，不一定與存儲(chǔ)順序一樣邻寿，磁盤(pán)上記錄的順序也不一定與INSERT的記錄順序一樣蝎土，這也是我用同樣條件沒(méi)有測(cè)試出死鎖的原因（我的環(huán)境中，恰好讀出的順序與INSERT的順序不一樣）
更新時(shí)绣否，記錄讀取的順序瘟则，可以通過(guò)Profile跟蹤的Lock:Acquired?(加鎖)事件來(lái)看，涉及大量數(shù)據(jù)時(shí)枝秤，如果服務(wù)器支持，還會(huì)有并發(fā)讀取慷嗜。這也是分析死鎖時(shí)要考慮的因素
