上一篇我只是做了一個(gè)堆表讓大家初步的認(rèn)識(shí)到鎖的痙攣狀態(tài)，但是在現(xiàn)實(shí)世界上并沒(méi)有這么簡(jiǎn)單的事情，起碼我的表不會(huì)沒(méi)有索引對(duì)吧，，，還

有就是我的表一定會(huì)有很多的連接過(guò)來(lái)，10:1的讀寫(xiě)，很多碼農(nóng)可能都會(huì)遇到類(lèi)似神乎其神的死鎖，卡住，讀不出來(lái)，插不進(jìn)入等等神仙的事情導(dǎo)致性

能低下，這篇我們一起來(lái)探討下。

一： 當(dāng)select遇到性能低下的update會(huì)怎么樣？

1. 還是使用原始的person表，插入6條數(shù)據(jù)，由于是4000字節(jié)，所以兩條數(shù)據(jù)就是一個(gè)數(shù)據(jù)頁(yè)，如下圖：

1 DROP TABLE dbo.Person
2 CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(4000) DEFAULT 'aaaaa')
3 --插入6條數(shù)據(jù)，剛好3個(gè)數(shù)據(jù)頁(yè)
4 INSERT INTO dbo.Person DEFAULT VALUES
5 go 6

2. 為了模擬性能低下的Update操作，我們開(kāi)個(gè)顯式事務(wù)來(lái)更新ID=4的記錄，并且用profile看一下，如下圖：

1 BEGIN TRAN
2 UPDATE dbo.Person SET NAME='bbbbb' WHERE id=4

3. 然后我們開(kāi)下另一個(gè)會(huì)話連接，讀取ID=6的記錄會(huì)是怎樣？？？？好奇嗎？？？？

1 SELECT * FROM Person WHERE ID=6

從上面流程你是否看到，當(dāng)掃描到89號(hào)數(shù)據(jù)頁(yè)的slot1槽位的時(shí)候卡住了。。。我想你應(yīng)該知道update正好已經(jīng)給這條記錄加上了X鎖。。。如果你

夠細(xì)心，你還會(huì)發(fā)現(xiàn)，給S鎖附加記錄的條件是在當(dāng)引擎發(fā)現(xiàn)記錄所在的數(shù)據(jù)頁(yè)已經(jīng)附加上了IX鎖的情況下，才給該號(hào)數(shù)據(jù)頁(yè)下的每條記錄附加S鎖，

對(duì)吧。。。好了，既然在Profile上面看不到了，我還是有其他辦法來(lái)判斷到底select語(yǔ)句現(xiàn)在處于什么狀態(tài)。

4. 使用sys.dm_tran_locks來(lái)看當(dāng)前各個(gè)連接持有鎖的狀態(tài)。

1 SELECT  l.request_session_id,
2         DB_NAME(l.resource_database_id),OBJECT_NAME(p.object_id),
3         l.resource_description,l.request_type,
4         l.request_status,request_mode 
5 FROM sys.dm_tran_locks AS l
6 LEFT JOIN sys.partitions AS p
7 ON l.resource_associated_entity_id=p.hobt_id

仔細(xì)觀察上圖可以看到，當(dāng)前有51和52號(hào)會(huì)話，51號(hào)在1:89:1槽位上使用了X鎖并且沒(méi)有釋放，52號(hào)此時(shí)也進(jìn)入了1:89:1中，并且想給該

RowID附加S鎖，但是你也知道S和X鎖是排斥的，所以很無(wú)奈的一直保持等待狀態(tài)。

二：使用索引或許可以幫你逃過(guò)一劫

　　當(dāng)你看完上面的講敘，是不是有點(diǎn)害怕？？？要是在生產(chǎn)環(huán)境下出現(xiàn)了這種情況，那我們是不是死的很慘？？？那接下來(lái)使用索引是不是真

的可以幫我們躲過(guò)一劫呢？？？下面跟我一起看一看。

1. 新建索引index

1 -- 在ID列上建一個(gè)index
2 CREATE INDEX idx_person ON dbo.Person(ID)

2. 然后我們看下數(shù)據(jù)頁(yè)的分布情況，可以看到下圖中78,89,90是表數(shù)據(jù)頁(yè)，93號(hào)為索引數(shù)據(jù)頁(yè)。

1 DBCC TRACEON(2588,3604)
2 DBCC IND(Ctrip,Person,-1)

3. 麻蛋的，繼續(xù)執(zhí)行上面的那個(gè)慢update

BEGIN TRAN
UPDATE dbo.Person SET NAME='bbbbb' WHERE id=4

4. 激動(dòng)人心的時(shí)刻來(lái)了，由于數(shù)據(jù)太少，所以我這里強(qiáng)制讓引擎執(zhí)行我創(chuàng)建的索引，看看結(jié)果怎樣？

居然沒(méi)卡??？？？現(xiàn)在是不是有一股強(qiáng)烈的好奇心來(lái)了，狗狗狗。。。馬上開(kāi)啟profile，看看到底都發(fā)生了什么？？？

仔細(xì)看完這個(gè)圖，是不是覺(jué)得很有意思呢？？？具體步驟如下：

第一步：給表（Object）加上IS鎖。

第二步：因?yàn)橐咚饕?，給93號(hào)索引數(shù)據(jù)頁(yè)加上IS鎖。

第三步：找到93號(hào)索引數(shù)據(jù)頁(yè)的目標(biāo)key，給這個(gè)key加上S鎖，有人可能就會(huì)問(wèn)了。。。這個(gè)key不就是6嘛，為什么這個(gè)key=(61005a25560e)，

　　　　你要是太好奇我可以告訴你，年輕人說(shuō)話不要太屌，每行索引記錄都有一個(gè)散列值，這個(gè)值就是根據(jù)索引的幾個(gè)字段散列出來(lái)的，好處就是

　　      防止你的索引長(zhǎng)度過(guò)大，導(dǎo)致鎖這個(gè)記錄的時(shí)候太耗費(fèi)鎖空間了。。。。如果你還是不太相信的話，我用DBCC給你看一看。　　　　　　

第四步：根據(jù)這個(gè)key直接跳到存放記錄的90號(hào)數(shù)據(jù)頁(yè)中，萬(wàn)幸的是update的記錄剛好不在90號(hào)數(shù)據(jù)頁(yè)中。。。。就這樣躲過(guò)一劫了。。。然

　　     后select順利的讀取到了該讀的記錄，最后釋放相關(guān)的IS鎖。

　　如果你看懂了上面所說(shuō)的幾點(diǎn)，我想你對(duì)鎖已經(jīng)入門(mén)了，如果覺(jué)得還是有些糊涂的話，沒(méi)關(guān)系。。。你有了profile利器，，，自己多試驗(yàn)試

驗(yàn)就好，畢竟我也是這樣，晚上再發(fā)布最后一篇，明天晚上回家。。。這樣就可以安心順利的過(guò)大年了。