1.性能低下的update会怎么样？
(1).使用原始的person表，插入6条数据，由于是4000字节，所以两条数据就是一个数据页
drop table dbo.person;
create table person(id int identity,name char(4000) default 'aaaaa');
--插入6条数据，刚好3个数据页
insert into dbo.person default values;
go
(2).为了模拟性能低下的Update操作，我们开个显式事务来更新ID=4的记录，并且用profile看一下
begin tran
update dbo.person set name='bbbbb' where id=4;
(3).然后我们开下另一个会话连接，读取ID=6的记录
select * from person where id=6;
从上面流程你是否看到，当扫描到89号数据页的slot1槽位的时候卡住了。。。我想你应该知道update正好已经给这条记录加上了X锁。。。如果你够细心，你还会发现，给S锁附加记录的条件是在当引擎发现记录所在的数据页已经附加上了IX锁的情况下，才给该号数据页下的每条记录附加S锁，对吧。。。好了，既然在Profile上面看不到了，我还是有其他办法来判断到底select语句现在处于什么状态。
(4).使用sys.dm_tran_locks来看当前各个连接持有锁的状态
SELECT l.request_session_id,
DB_NAME(l.resource_database_id),
OBJECT_NAME(p.object_id),
l.resource_description,
l.request_type,
l.request_status,
request_mode
FROM sys.dm_tran_locks AS l
LEFT JOIN sys.partitions AS p
ON l.resource_associated_entity_id = p.hobt_id;
仔细观察上图可以看到，当前有51和52号会话，51号在1:89:1槽位上使用了X锁并且没有释放，52号此时也进入了1:89:1中，并且想给该RowID附加S锁，但是你也知道S和X锁是排斥的，所以很无奈的一直保持等待状态。
2.使用索引解决此问题
(1).新建索引index
create index idx_person on dbo.person(id);
(2).然后我们看下数据页的分布情况，可以看到下图中78,89,90是表数据页，93号为索引数据页
dbcc traceon(2588,3604)
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锁。
