不幸的是，这不仅仅是读取未提交的数据。在后台，您可能会读两次页面(在页面分割的情况下)，或者您可能会完全错过这些页面。所以你的结果可能是严重扭曲的。

看看Itzik Ben-Gan的文章。以下是节选:

" With the NOLOCK hint (or setting the isolation level of the session to READ UNCOMMITTED) you tell SQL Server that you don't expect consistency, so there are no guarantees. Bear in mind though that "inconsistent data" does not only mean that you might see uncommitted changes that were later rolled back, or data changes in an intermediate state of the transaction. It also means that in a simple query that scans all table/index data SQL Server may lose the scan position, or you might end up getting the same row twice. "

NOLOCK相当于READ UNCOMMITTED，但是微软说你不应该在UPDATE或DELETE语句中使用它:

对于UPDATE或DELETE语句:此功能将在Microsoft SQL Server的未来版本中删除。避免在新的开发工作中使用此特性，并计划修改当前使用此特性的应用程序。

http://msdn.microsoft.com/en-us/library/ms187373.aspx

本文适用于SQL Server 2005，因此如果您使用的是该版本，就会支持NOLOCK。为了保证你的代码不受未来的影响(假设你决定使用脏读)，你可以在你的存储过程中使用这个:

设置事务隔离级别读未提交

另一种通常可以接受的情况是在报告数据库中，其中的数据可能已经老化，不会发生写入操作。但是，在这种情况下，管理员应该通过更改默认隔离级别在数据库或表级别设置该选项。

在一般情况下:当你非常确定可以读取旧数据时，你可以使用它。重要的是要记住这很容易出错。例如，即使在编写查询时没有问题，但您确定将来数据库中不会有什么变化使这些更新变得更重要吗?

我还想说的是，在银行应用程序或库存应用程序中，这可能不是一个好主意。

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

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

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

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

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

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

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

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

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

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