如果你正在处理金融交易，那么你永远不会想要使用nolock。Nolock最适合用于从具有大量更新的大型表中进行选择，并且您不关心所获得的记录是否可能过期。

对于财务记录(以及大多数应用程序中的几乎所有其他记录)，nolock会造成严重破坏，因为您可能会从正在写入的记录中读取数据，而得不到正确的数据。

nolock提示合法使用的教科书示例是针对高更新OLTP数据库的报告采样。

举个热门的例子。如果美国一家大型商业银行想要每小时发布一份报告，寻找城市层面的挤兑的最初迹象，那么nolock查询可以扫描每个城市的现金存取款总和的交易表。对于这样的报告，由回滚更新事务引起的微小百分比的错误不会降低报告的价值。

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

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

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

最简单的答案就是一个简单的问题——你需要你的结果是可重复的吗?如果是，那么NOLOCKS在任何情况下都不合适

如果你不需要可重复性，那么nolock可能是有用的，特别是当你不能控制所有连接到目标数据库的进程时。

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

WITH (NOLOCK)相当于使用READ uncommitted作为事务隔离级别。因此，您可能会读取一个未提交的行，该行随后会被回滚，即从未进入数据库的数据。因此，虽然它可以防止读取被其他操作死锁，但也存在风险。在具有高交易率的银行应用程序中，它可能不是您试图用它解决的任何问题的正确解决方案。