Sql Server 深入的探讨锁机制

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

仔细观察上图可以看到，当前有51和52号会话，51号在1:89:1槽位上使用了X锁并且没有释放，52号此时也进入了1:89:1中，并且想给该

RowID附加S锁，但是你也知道S和X锁是排斥的，所以很无奈的一直保持等待状态。

二：使用索引或许可以帮你逃过一劫

　　当你看完上面的讲叙，是不是有点害怕？？？要是在生产环境下出现了这种情况，那我们是不是死的很惨？？？那接下来使用索引是不是真

的可以帮我们躲过一劫呢？？？下面跟我一起看一看。

1. 新建索引index

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

2. 然后我们看下数据页的分布情况，可以看到下图中78,89,90是表数据页，93号为索引数据页。

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

3. 麻蛋的，继续执行上面的那个慢update

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

4. 激动人心的时刻来了，由于数据太少，所以我这里强制让引擎执行我创建的索引，看看结果怎样？

居然没卡住？？？现在是不是有一股强烈的好奇心来了，狗狗狗。。。马上开启profile，看看到底都发生了什么？？？

仔细看完这个图，是不是觉得很有意思呢？？？具体步骤如下：

第一步：给表（Object）加上IS锁。

第二步：因为要走索引，给93号索引数据页加上IS锁。

第三步：找到93号索引数据页的目标key，给这个key加上S锁，有人可能就会问了。。。这个key不就是6嘛，为什么这个key=(61005a25560e)，

　　　　你要是太好奇我可以告诉你，年轻人说话不要太屌，每行索引记录都有一个散列值，这个值就是根据索引的几个字段散列出来的，好处就是

　　      防止你的索引长度过大，导致锁这个记录的时候太耗费锁空间了。。。。如果你还是不太相信的话，我用DBCC给你看一看。　　　　　　

第四步：根据这个key直接跳到存放记录的90号数据页中，万幸的是update的记录刚好不在90号数据页中。。。。就这样躲过一劫了。。。然

　　     后select顺利的读取到了该读的记录，最后释放相关的IS锁。

　　如果你看懂了上面所说的几点，我想你对锁已经入门了，如果觉得还是有些糊涂的话，没关系。。。你有了profile利器，，，自己多试验试

验就好，毕竟我也是这样，晚上再发布最后一篇，明天晚上回家。。。这样就可以安心顺利的过大年了。

Sql Server 深入的探讨锁机制

标签：