概念介紹

開發人員喜歡在SQL腳本中使用WITH(NOLOCK), WITH(NOLOCK)其實是表提示（table_hint）中的一種。它等同于 READUNCOMMITTED 。 具體的功能作用如下所示（摘自MSDN）：

1： 指定允許臟讀。不發布共享鎖來阻止其他事務修改當前事務讀取的數據，其他事務設置的排他鎖不會阻礙當前事務讀取鎖定數據。允許臟讀可能產生較多的并發操作，但其代價是讀取以后會被其他事務回滾的數據修改。這可能會使您的事務出錯，向用戶顯示從未提交過的數據，或者導致用戶兩次看到記錄（或根本看不到記錄）。有關臟讀、不可重復讀和幻讀的詳細信息，請參閱并發影響。

2： READUNCOMMITTED 和 NOLOCK 提示僅適用于數據鎖。所有查詢（包括那些帶有 READUNCOMMITTED 和 NOLOCK 提示的查詢）都會在編譯和執行過程中獲取 Sch-S（架構穩定性）鎖。因此，當并發事務持有表的 Sch-M（架構修改）鎖時，將阻塞查詢。例如，數據定義語言 (DDL) 操作在修改表的架構信息之前獲取 Sch-M 鎖。所有并發查詢（包括那些使用 READUNCOMMITTED 或 NOLOCK 提示運行的查詢）都會在嘗試獲取 Sch-S 鎖時被阻塞。相反，持有 Sch-S 鎖的查詢將阻塞嘗試獲取 Sch-M 鎖的并發事務。有關鎖行為的詳細信息，請參閱鎖兼容性（數據庫引擎）。

3: 不能為通過插入、更新或刪除操作修改過的表指定 READUNCOMMITTED 和 NOLOCK。SQL Server 查詢優化器忽略 FROM 子句中應用于 UPDATE 或 DELETE 語句的目標表的 READUNCOMMITTED 和 NOLOCK 提示。

功能與缺陷

使用WIHT(NOLOCK)有利也有弊，所以在決定使用之前，你一定需要了解清楚WITH(NOLOCK)的功能和缺陷，看其是否適合你的業務需求,不要覺得它能提升性能，稀里糊涂的就使用它。

1：使用WITH(NOLOCK)時查詢不受其它排他鎖阻塞

打開會話窗口1，執行下面腳本，不提交也不回滾事務，模擬事務真在執行過程當中

BEGIN TRAN

       UPDATE TEST SET NAME='Timmy' WHERE OBJECT_ID =1;

       --ROLLBACK

打開會話窗口2，執行下面腳本，你會發現執行結果一直查詢不出來（其實才兩條記錄）。當前會話被阻塞了

SELECT * FROM TEST;

打開會話窗口3，執行下面腳本，查看阻塞情況，你會發現在會話2被會話1給阻塞了，會話2的等待類型為LCK_M_S：“當某任務正在等待獲取共享鎖時出現”

  SELECT wt.blocking_session_id                    AS BlockingSessesionId

        ,sp.PRogram_name                           AS ProgramName

        ,COALESCE(sp.LOGINAME, sp.nt_username)     AS HostName    

        ,ec1.client_net_address                    AS ClientipAddress

        ,db.name                                   AS DatabaseName