在SQL Server的每個SELECT中使用（nolock）會導致什麼情況？

Question

我知道(nolock)優化器提示允許「髒讀」，但在特定情況下這是一個壞主意？我從未在組織中看到如此廣泛的使用(nolock)，這讓我感到緊張。我想用用戶故事來解釋。 「保羅做A，彼得做B，X發生而不是Y」。

Answer 1

轉貼this答案：

---

NOLOCK意味着將沒有鎖的。

您的查詢可能會返回UPDATE之前的部分數據，以及UPDATE之後的部分在單個查詢中。

像，沒有信用和這些東西的借方。

舉例來說，我只是跑了一大桌此查詢：

SELECT SUM(LEN(name)) 
FROM master WITH (NOLOCK) 
OPTION (MAXDOP 1) 

--- 
18874367 

所有name的有1長度。

然後我重新它，並在查詢中更新的表的中間：

UPDATE master 
SET  name = 'tt' 
WHERE id <= 10000 

SELECT SUM(LEN(name)) 
FROM master WITH (NOLOCK) 
OPTION (MAXDOP 1) 

--- 
18874944 

我們可以看到，這個查詢發現577行作爲更新（長度2），不更新所有其他行（長度1）。

SELECT SUM(LEN(name)) 
FROM master WITH (NOLOCK) 
OPTION (MAXDOP 1) 

--- 
18884367 

而這個查詢，在前一個完成後運行，看到所有更新。

Answer 2

我最近花了很多時間找出數據倉庫構建過程的一些時間並阻止了問題。事實證明，由於用於加載倉庫的數據的只讀屬性，我在etl的源數據查詢中添加了nolock提示，以減少sql服務器上鎖升級的需求並保持etl負載不發生故障。對於這一個我很少控制SQL服務器和應用程序。再次，這是一個有針對性的解決方案，我不推薦廣泛使用任何查詢提示作爲一般規則。像所有的性能測試和評估一樣，有一些關鍵的方面需要考慮來確定問題的出在哪裏，以及什麼可能是最好的攻擊方式。

Answer 3

查看此鏈接的例子。

http://blogs.msdn.com/davidlean/archive/2009/04/06/sql-server-nolock-hint-other-poor-ideas.aspx