時間:2024-03-13 13:57作者:下載吧人氣:22
前言
在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
網友評論