一個SELECT如何阻塞另一個？

我正在查看SQL Server 2005上的SP_WhoIsActive的輸出，它告訴我一個會話阻塞了另一個會話 - 沒問題。但是他們都在運行一個SELECT。一個SELECT如何阻止另一個？他們是不是應該獲得共享鎖（它們是相互兼容的）？一個SELECT如何阻塞另一個？

一些細節：兩個會話都沒有公開的交易計數 - 所以它們是獨立的。

查詢以表格的形式加入視圖。

他們是複雜的查詢，它加入了大量的表格，並且結果爲10,000個左右。

任何有識之士都非常感謝。

來源

2010-06-08 Krip

SELECT語句可能會阻塞另一個SELECT語句。你可能認爲既然只獲得S鎖，它們就不應該阻塞。但是阻塞發生在各種類型的資源上，而不僅僅是鎖。典型的例子是內存限制。我將嘗試挖掘一個最近對這個問題的回答，這個問題附帶了一個顯示給SELECT語句的死鎖圖表，其中一個正在等待另一個表示並行交換操作符內存資源（緩衝區）。

更新這裏是死鎖信息的鏈接我談到：I have data about deadlocks, but I can't understand why they occur 如果你研究的僵局圖，你會發現在等待列表如下資源：

<exchangeEvent id="Pipe894b0680" WaitType="e_waitPipeGetRow" nodeId="0"> 
    <owner-list> 
    <owner id="process824df048"/> 
    </owner-list> 
    <waiter-list> 
    <waiter id="process86ce0988"/> 
    </waiter-list> 
</exchangeEvent>

這不是一個鎖，是'e_waitPipeGetRow'資源，由SELECT擁有，另一個SELECT正在等待它。關於「查詢內並行資源」的一些討論可以在這裏找到：Today's Annoyingly-Unwieldy Term: "Intra-Query Parallel Thread Deadlocks"。雖然大多數討論都將關注於死鎖問題，但這並不意味着這些資源上不會發生普通阻塞。 sys.dm_exec_requests將在wait_type和wait_resource中有適當的信息。

來源

2010-06-08 18:49:22

非常感謝你的信息！ – Krip 2010-06-09 09:15:20

我認爲它是因爲第一個選擇是執行行鎖定/表鎖定。在加入表格時，您可以提供NO LOCK提示。

來源

2010-06-08 18:47:01 Chinjoo

根據我今天的經驗，NO LOCK提示不足以阻止真正的查詢內並行線程死鎖事件。 – 2013-04-19 02:16:58

不建議使用NO LOCK。它可能導致髒讀（重複數據，缺失數據）。鎖定是保持數據一致性的有意的機制。在您的危險中使用無鎖。 http://blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere/ – Davos 2015-08-04 05:01:48

一個SELECT如何阻塞另一個？

回答

相關問題