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

可是很多人都疑惑，為什么我使用了ReadPast仍然有時會被阻塞？

首先我們找到聯機幫助：

READPAST

指定數據庫引擎不讀取由其他事務鎖定的行。 如果指定了 READPAST，將跳過行級鎖。 也就是說，數據庫引擎將跳過這些行，而不是阻塞當前事務直到鎖被釋放。 例如，假設表 T1 包含一個單精度整數列，其值為 1、2、3、4 和 5。 如果事務 A 將值 3 更改為 8，但尚未提交，則 SELECT * FROM T1 (READPAST) 將生成值 1、2、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 pon 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) 

總結：

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

總之，DBA會一直和阻塞、死鎖做著長期的、不懈的斗爭。。。。。