在我們的應用程序登錄過程中，有幾個查詢運行，全部驗證登錄。在評估他們時，我注意到其中一個查詢運行時沒有NOLOCK提示。查詢中的SQL Server NOLOCK運行授權
似乎沒有任何特別的髒讀危險，因爲數據幾乎不會改變。
從嘗試的DOS類型的攻擊中反覆嘗試嘗試失敗的登錄我認爲缺乏NOLOCK降低了我們的失敗門檻。我相信這是一個DOS攻擊（我認爲Web服務器會先發生）的一個極不可能的結果，但添加NOLOCK應該使它從不可能變爲不可能。
那麼，我過度還是微不足道？
有NOLOCKs或沒有NOLOCKs是您對您的服務器的DoS嘗試的擔心最少。
我不會爲此而出汗。
如您所說，如果數據很少發生變化，那麼使用NOLOCK可能不會造成傷害。
也是一種非常罕見的情況，但仍然存在：就在此時有人停用用戶以防止他們登錄，NOLOCK讓他們進入。可能是需要立即鎖定的流氓用戶/黑客/員工？
您將不得不關注這種特殊情況，以放棄NOLOCK的性能優勢。
如果您經常調用該查詢，尤其是在更廣泛的事務中，則NOLOCK可能會提高性能。
考慮髒讀的性質 - 可能發生的時間窗口是否真的很關鍵？例如您在授權角色中添加或刪除某人的位置。
在添加方案中，髒讀將在該嘗試中失敗。 （拒絕訪問）
在刪除場景中，髒讀將會對該嘗試起作用。 （准許訪問）
如果數據通過手動操作改變，例如，人際交互 - 「延遲」的餘量通常比數據庫高得多/不確定！
是的，你正在過分瑣碎。
如果您遇到DOS攻擊，SQL授權調用中的NOLOCK是您最擔心的問題。實現一些DOS檢測，失敗跟蹤+節流，甚至一些計劃中的暫停，不會影響用戶，但會減緩攻擊...
通過查看權限，您可以更好地保護您的表。像這樣的表不應該允許任何直接訪問，所有的訪問都應該來自存儲的特效以及設置的權限。
我同意那些事情需要到位，但在我的情況下，這是我無法控制的。我只能控制軟件本身的安全性。 – Flory 2008-11-12 16:10:18