1、新建一个表，插入1010000数据：

create table test(id int identity(1,1) ,name varchar(600)) 
go

insert into test
values(replicate('a',600));
go 1010000

create index idx_test_id on test(id)

2、新开一个会话（A），运行如下语句，由于没有提交，所以会阻塞其他药修改相同数据的会话：

begin tran
	update test 
	set name = replicate('f',500)
	where id = 100000

3、再新开一个会话（B），运行如下语句，由于需要修改id为 100000的数据，所以被上一个会话A阻塞了。

需要特别注意的是，在语句中使用了查询提示repeatableread，那么select语句对记录获取的S锁，只有在commit或rollback时，才会释放。

begin tran

select *
from test with(repeatableread)
where id >= 9000 and id <= 100000

select  sysdatetime()

begin tran
	  
	update test 
	set name = replicate('k',589)
	where id = 100000

	select  sysdatetime() 

5、在会话A中，通过commit来提交事务，这个时候，会话B会马上返回结果，但会话C还是继续被阻塞，这个时候C被B会话阻塞。

接下来，在会话B中执行commit，于是会话C立即返回。

从以上的现象大致能看出，数据库锁中的队列机制，也就是当很多会话都需要访问相同的资源时，会有一个队列机制，一开始A对资源加上独占锁，获取到资源，但没有提交，所以没有释放资源上的锁。

会话B也需要访问相同的资源，由于会话需要读数据，所以需要加上共享锁，但由于共享锁和之前资源上的独占锁，不兼容，就导致了会话B被阻塞住了，那么会话B就进入到一个等待队列里。

会话C也需要访问相同的资源，由于需要修改数据，所以需要加上独占锁，但于会话A已加上的独占锁，不兼容，于是会话C也被阻塞住了，那么会话C也会进入到等待队列中，排在会话B之后。

会话C被阻塞的原因：

从上图可以看出，会话C在把Page 1 ：21339上的IU锁改为IX锁时，没有grant，而是处于convert状态，之所要修改，是因为需要修改id为100000的数据。

而之前已经在1 ：21339上加了IU锁，在RID 1:21339:1 上加了U锁，要修改这个这个页中的数据，必须要把IU锁修改为IX锁，如果成功，那么继续把U锁修改为X锁。

从上述分析中，可以看出SQL Server中的锁采用是队列的机制，即先进先出。