SQL Server 锁的排队机制

w5wfwe

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()  


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



    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中的锁采用是队列的机制，即先进先出。