With(ReadPast)就不會被阻塞嗎？

在生產環境中，會有不少使用ReadPast查詢提示的場合，來避免正在被其它事務鎖定的行對當前查詢形成阻塞，而又不會獲取到「髒數據」。

但是不少人都疑惑，爲何我使用了ReadPast仍然有時會被阻塞？

首先咱們找到聯機幫助：

READPAST

指定數據庫引擎不讀取由其餘事務鎖定的行。 若是指定了 READPAST，將跳過行級鎖。 也就是說，數據庫引擎將跳過這些行，而不是阻塞當前事務直到鎖被釋放。 例如，假設表 T1 包含一個單精度整數列，其值爲 一、二、三、4 和 5。 若是事務 A 將值 3 更改成 8，但還沒有提交，則 SELECT * FROM T1 (READPAST) 將生成值 一、二、4 和 5。 使用 SQL Server 表實現工做隊列時，READPAST 主要用於減小鎖定爭用。 使用 READPAST 的隊列讀取器會跳過被其餘事務鎖定的隊列項，跳至下一個可用的隊列項，而不是等待其餘事務釋放鎖。

一切看起來都很美好，可是請看以下場景：

表名[IP]，彙集索引字段：BIP

會話一：

BEGIN TRAN
    SELECT * FROM ip WITH(XLOCK) WHERE BIP='1.10.8.0'

而後去會話二，執行：

SELECT * FROM ip WITH(READPAST) 

發現會話二被阻塞了

Why？

咱們經過系統視圖sys.dm_tran_locks來看看發生了什麼：

SELECT request_session_id, resource_type, 
    request_status, request_mode,
    resource_description, object_name(p.object_id) as object_name,p.index_id
    FROM sys.dm_tran_locks left join sys.partitions p
on sys.dm_tran_locks.resource_associated_entity_id = p.hobt_id

上圖中能夠看到，會話二(ID61)中的select妄圖獲取page(1:23952)上的S共享鎖，卻被會話一(ID56)在該page上的IX意向排它鎖給攔住了

爲何？說好的會跳過其它事務鎖定的行呢？

「等等，你剛纔說的最後一個字是什麼？」

「呢」？

「不是，再上一個！「

」行「？

」對了！「

指定數據庫引擎不讀取由其餘事務鎖定的行。 若是指定了 READPAST，將跳過行級鎖。

在會話二中，咱們使用了select * ，而且沒有where條件，執行計劃會使用匯集索引掃描：

掃描意味着什麼？在每一個掃描過的page上都會加S共享鎖！！

而，若是指定where條件，而且執行計劃是彙集索引查找的話，則只會在所查找的頁面上獲取IS意向共享鎖!

（該查詢返回空結果集）

知道了以上區別，咱們再來看看SQLServer鎖兼容圖表：

再來回想一下整個過程，在會話一中，咱們使用XLOCK提示，使得SQLServer獲取了一個Page上的意向排它鎖IX，而且保持事務。

在會話二中咱們使用了彙集索引掃描的查詢計劃，使得在每個頁面上都會申請S共享鎖，從上面的圖紅圈處可見，S是與IX互斥的，故該查詢會被阻塞，而指定了where條件的查詢，申請的是page上的IS意向共享鎖，上面圖綠圈處可見，IS與IX是不衝突的，故不會被阻塞。

 

說到這裏，我有想起了鎖提示ROWLOCK，聯機叢書解釋以下：

ROWLOCK

指定一般採用頁鎖或表鎖時，採用行鎖。 在從 SNAPSHOT 隔離級別操做的事務中指定時，除非將 ROWLOCK 與須要鎖的其餘表提示（例如，UPDLOCK 和 HOLDLOCK）組合，不然不會取得行鎖。

 

聽這解釋，貌似能夠解決咱們上面說的阻塞的問題啊，那讓咱們來試一下：

 

SELECT * FROM ip WITH(ROWLOCK) 

果真能夠！！

咱們看一下這個查詢提示獲取的是什麼鎖：

噢！它獲取的是PAGE上的意向共享鎖，和指定where條件時在查找的頁上獲取的鎖是相同的，因此沒有被阻塞！

 

總結：

        SQLServer每一個阻塞都是有緣由的，瞬間的、少許的阻塞並非不可原諒的，在高併發的系統中都是正常的，可是頻繁的，長時間的阻塞（我的認爲200ms以上都是值得注意的），就應該引發DBA的重視，搞清楚緣由是什麼。阻塞源沒有儘快完成事務的緣由多種多樣，多是事務內的的語句效率問題，多是程序端調用時出現了交互或者中途錯誤、多是數據庫服務器系統資源出了問題。

總之，DBA會一直和阻塞、死鎖作着長期的、不懈的鬥爭。。。。。