在SQL Server中，我們知道一個SELECT語句執(zhí)行過程中只會申請一些意向共享鎖(IS) 與共享鎖(S), 例如我使用SQL Profile跟蹤會話86執(zhí)行SELECT * FROM dbo.TEST WHERE OBJECT_ID =1 這個查詢語句，其申請、釋放的鎖資源的過程如下所示：

?

?

而且從最常見的鎖模式的兼容性表，我們可以看到IS鎖與S鎖都是兼容的，也就是說SELECT查詢是不會阻塞SELECT查詢的。

	現(xiàn)有的授權(quán)模式
請求的模式	IS	S	U	IX	SIX	X
意向共享 (IS)	是	是	是	是	是	否
共享 (S)	是	是	是	否	否	否
更新 (U)	是	是	否	否	否	否
意向排他 (IX)	是	否	否	是	否	否
意向排他共享 (SIX)	是	否	否	否	否	否
排他 (X)	否	否	否	否	否	否

但是在某些特殊場景。你會看到SELECT語句居然“阻塞”SELECT操作，那么SQL Server中SELECT會真的阻塞SELECT操作嗎？我們先構(gòu)造測試的案例場景，那么先準備測試數(shù)據(jù)吧

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中，執(zhí)行下面SQL語句，模擬一個UPDATE語句正在執(zhí)行

?

BEGIN?TRANSACTION

?

??? UPDATE dbo.TEST SET NAME='Kerry'?WHERE OBJECT_ID=1;

??? --ROLLBACK;

?

會話窗口B中，執(zhí)行下面的SQL語句

SELECT * FROM dbo.TEST WHERE OBJECT_ID=1

?

會話窗口C中，執(zhí)行下面的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來查看，你會發(fā)現(xiàn)也是如此，如下所示：

?

如下所示，我們會發(fā)現(xiàn)會話ID為90 、87的會話都在等待類型為RID，Resource為1:24171:1的共享鎖

?

其實應(yīng)該說，會話87、90都在等待RID對象的共享鎖，我們知道共享鎖與意向共享鎖都是兼容的，所以SELECT是不會阻塞SELECT的，那么又怎么解釋這個現(xiàn)象呢？在宋大神的指點下，粗略的翻了Database System Implementaion這本書（很多原理性知識，看起來相當(dāng)吃力）。里面介紹了在鎖表（lock table）以及Element Info、Handling Lock Requests、Handling Unlocks等概念,有一個有意思的圖所示，

?

在鎖表（lock table）里，elements info里的鎖的申請是在一個類似隊列的結(jié)構(gòu)。先進先出機制，所以當(dāng)會話90先進入隊列，它在等待共享鎖（S), 會話87也進入隊列等待共享鎖(S)，而且它在會話90的后面（即會話90這個elements info后面的Next指針指向會話87會話的事務(wù)）,由于兩個會話都被阻塞，這兩個會話的Wait字段都是Yes，由于內(nèi)部某些機制，會話87顯示阻塞它的會話為90（這個是我個人臆測，實際具體原因有待考究），實質(zhì)阻塞的源頭還是會話85. 當(dāng)會話85釋放排它鎖（X）后，會話隊列根據(jù)下面幾個原則來處理解鎖（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

先來先服務(wù)（隊列的原則）：授予鎖等待時間最長的鎖請求，這種策略保證不會餓死（翻譯感覺不貼切），即一個事務(wù)不會永遠等待鎖的情況。

?

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.

共享鎖優(yōu)先，首先授予所有等待共享鎖（S），然后授予其中一個更新鎖（U),如果有其它類型等待，只有在沒有其它鎖等待時，才授予排它鎖、這一策略允許等待更新鎖或排它鎖的事務(wù)餓死（結(jié)束）

?

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.

鎖升級優(yōu)先，如果有一個持有共享鎖（U)等待升級Wie排他鎖（X),那么先授予它排它鎖，否則采用前面已經(jīng)提到的策略中的一個。

?

按照這些原則，當(dāng)會話85釋放了排它鎖（X)后，調(diào)度器（Scheduler）應(yīng)該會根據(jù)先后順序依次授予會話90、87共享鎖（S),兩者的阻塞會幾乎同時消失。 這個可以也可以通過實驗進行一個大概的推斷， 在上面實驗中，你可以手工取消90會話的查詢操作，然后再查看阻塞情況，就會發(fā)現(xiàn)會話87被85阻塞了。這個阻塞的源頭就變成了85，而不是90了。

?

PS:上面是個人結(jié)合一些知識和理解，做的一些膚淺的判斷與分析，如果不對的地方，敬請指正！

?

參考資料：

Database System Implementaion

轉(zhuǎn)載于:https://www.cnblogs.com/kerrycode/p/6250606.html

總結(jié)

以上是生活随笔為你收集整理的SQL Server中SELECT会真的阻塞SELECT吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。