SQL Server中的SELECT会阻塞SELECT吗

前言

在SQL Server中，我们晓得一个SELECT语句施行历程中只会申请一些意向同享锁(IS) 与同享锁(S), 例如我运用SQL Profile跟踪会话86施行SELECT * FROM dbo.TEST WHERE OBJECT_ID =1 这个查询语句，其申请、释放的锁资源的历程如下所示：

而且从最常见的锁模式的兼容性表，我们可以看到IS锁与S锁都是兼容的，也就是说SELECT查询是不会阻塞SELECT查询的。

	现有的授权模式
请求的模式	IS	S	U	IX	SIX	X
意向同享 (IS)	是	是	是	是	是	否
同享 (S)	是	是	是	否	否	否
更新 (U)	是	是	否	否	否	否
意向排他 (IX)	是	否	否	是	否	否
意向排他同享(SIX)	是	否	否	否	否	否
排他 (X)	否	否	否	否	否	否

但是在某些特别场景。你会看到SELECT语句竟然“阻塞”SELECT操纵，那么SQL Server中SELECT会真的阻塞SELECT操纵吗？我们先结构测试的案例场景，那么先预备测试数据吧

CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(8));
 
CREATE INDEX PK_TEST ON TEST(OBJECT_ID) 
 
 
DECLARE @Index INT =0;
 
WHILE @Index < 20
BEGIN
 INSERT INTO TEST
 SELECT @Index, 'kerry';
 
 SET @Index = @Index +1;
END

在会话窗口A中，施行下面SQL语句，模拟一个UPDATE语句正在施行

BEGIN TRANSACTION
 
 UPDATE dbo.TEST SET NAME='Kerry' WHERE OBJECT_ID=1;
 --ROLLBACK;

会话窗口B中，施行下面的SQL语句

SELECT * FROM dbo.TEST WHERE OBJECT_ID=1

会话窗口C中，施行下面的SQL语句

SELECT * FROM dbo.TEST WHERE OBJECT_ID=1

我实验的场景下，会话窗口A的会话ID为85，会话窗口B的会话ID为90,会话窗口C的会话ID为87，如下所示

如下所示，你会看到SELECT语句“阻塞”了SELECT语句，即会话90“阻塞”了会话87， 它们的期待事件都为LCK_M_S,也就是说它们都在期待获取同享锁，或许你会置疑这个SQL是否有题目，那么我们运用SP_WHO来查看，你会发明也是如此，如下所示：

如下所示，我们会发明会话ID为90 、87的会话都在期待类型为RID，Resource为1:24171:1的同享锁

其实应当说，会话87、90都在期待RID对象的同享锁，我们晓得同享锁与意向同享锁都是兼容的，所以SELECT是不会阻塞SELECT的，那么又怎么解释这个现象呢？在宋大神的指点下，粗略的翻了Database System Implementaion这本书（许多道理性知识，看起来相当吃力）。里面介绍了在锁表（lock table）以及Element Info、Handling Lock Requests、Handling Unlocks等概念,有一个成心思的图所示，

在锁表（lock table）里，elements info里的锁的申请是在一个相似队列的构造。先进先出机制，所以当会话90先进入队列，它在期待同享锁（S), 会话87也进入队列期待同享锁(S)，而且它在会话90的背面（即会话90这个elements info背面的Next指针指向会话87会话的事务）,因为两个会话都被阻塞，这两个会话的Wait字段都是Yes，因为内部某些机制，会话87显示阻塞它的会话为90（这个是我个人揣测，现实具体缘由有待讲究），实质阻塞的泉源还是会话85. 当会话85释放排它锁（X）后，会话队列依据下面几个准则来处置解锁（Handling Unlocks）：

1： First-come-first-served: Grant the lock request that has been waiting the longest. This strategy guarantees no starvation, the situation where a transaction can wait forever for a lock

先来先服务（队列的准则）：授予锁期待工夫最长的锁请求，这种战略保证不会饿死（翻译感觉不贴切），即一个事务不会永远期待锁的状况。

2. Priority to shared locks: First grant all the shared locks waiting. Then,grant one update lock, if there are any waiting. Only grant an exclusive lock if no others are waiting. This strategy can allow starvation, if a transaction is waiting for a U or X lock.

同享锁优先，首先授予所有期待同享锁（S），然后授予其中一个更新锁（U),要是有其它类型期待，只要在没有其它锁期待时，才授予排它锁、这一战略允许期待更新锁或排它锁的事务饿死（完毕）

3. Priority to upgrading: If there is a transaction with a U lock waiting to upgrade it to an X lock, grant that first. Otherwise, follow one of the other strategies mentioned.

锁晋级优先，要是有一个持有同享锁（U)期待晋级Wie排他锁（X),那么先授予它排它锁，否则采纳前面已经提到的战略中的一个。

按照这些准则，当会话85释放了排它锁（X)后，调度器（Scheduler）应当会依据前后次序顺次授予会话90、87同享锁（S),两者的阻塞会险些同时消散。 这个可以也可以通过实验进行一个大约的推断， 在上面实验中，你可以手工取消90会话的查询操纵，然后再查看阻塞状况，就会发明会话87被85阻塞了。这个阻塞的泉源就变成了85，而不是90了。

PS:上面是个人联合一些知识和了解，做的一些肤浅的判断与剖析，要是不对的地方，敬请指正！

参考材料：

Database System Implementaion

总结

以上就是这篇文章的全部内容了，但愿本文的内容对大家的学习或者工作拥有一定的参考学习价值，要是有疑难大家可以留言交换，感谢大家对我们的支撑。