简单的答案-当你的SQL没有改变数据时，你有一个可能干扰其他活动的查询(通过锁定)。

对于用于报告的任何查询，都值得考虑，特别是当查询花费的时间超过1秒时。

如果您有针对OLTP数据库运行的olap类型的报告，那么它尤其有用。

第一个要问的问题是“我为什么要担心这个?”根据我的经验，当人们处于“尝试任何东西”模式时，通常会出现捏造默认锁定行为，而这种情况下意外的结果并非不可能发生。通常情况下，这是一个过早优化的情况，并且很容易嵌入到应用程序中“以防万一”。重要的是要了解你为什么要这样做，它解决了什么问题，以及你是否真的有问题。

简单的答案-当你的SQL没有改变数据时，你有一个可能干扰其他活动的查询(通过锁定)。

对于用于报告的任何查询，都值得考虑，特别是当查询花费的时间超过1秒时。

如果您有针对OLTP数据库运行的olap类型的报告，那么它尤其有用。

第一个要问的问题是“我为什么要担心这个?”根据我的经验，当人们处于“尝试任何东西”模式时，通常会出现捏造默认锁定行为，而这种情况下意外的结果并非不可能发生。通常情况下，这是一个过早优化的情况，并且很容易嵌入到应用程序中“以防万一”。重要的是要了解你为什么要这样做，它解决了什么问题，以及你是否真的有问题。

我过去常常检索“下一批”要做的事情。在这种情况下，具体是哪个项目并不重要，我有很多用户运行相同的查询。

我使用with (nolock)提示，特别是在SQLServer 2000数据库的高活动。我不确定在SQL Server 2005中是否需要它。我最近应客户端的DBA的请求在SQL Server 2000中添加了这个提示，因为他注意到有很多SPID记录锁。

我所能说的是，使用提示并没有伤害我们，似乎已经使锁定问题解决自己。那个特定客户的DBA坚持让我们使用这个提示。

顺便说一下，我处理的数据库是企业医疗索赔系统的后端，因此我们谈论的是许多连接中的数百万条记录和20多个表。我通常为连接中的每个表添加WITH (nolock)提示(除非它是派生表，在这种情况下，您不能使用该特定提示)

您可以在仅读取数据时使用它，并且并不真正关心是否可能返回尚未提交的数据。

它可以在读取操作上更快，但我不能确切地说快多少。

一般来说，我建议不要使用它——读取未提交的数据最多可能会有点混乱。

简短的回答:

对于有聚集索引的表，只能在SELECT语句中使用WITH (NOLOCK)。

长一点的回答:

WITH(NOLOCK)经常被用作加速数据库读取的神奇方法。

结果集可以包含尚未提交的行，这些行稍后通常会回滚。

如果WITH(NOLOCK)应用于具有非聚集索引的表，那么行索引可以由其他事务更改，因为行数据正在流到结果表中。这意味着结果集可能缺少行或多次显示同一行。

READ COMMITTED增加了一个额外的问题，即多个用户同时更改同一单元格时，单个列内的数据被损坏。