时间:2024-03-13 13:57作者:下载吧人气:23
前言
在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
网友评论