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

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

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

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

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

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

看看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. "

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

不确定为什么没有在数据库事务中包装金融事务(当您将资金从一个帐户转移到另一个帐户时—您不每次提交事务的一方—这就是显式事务存在的原因)。即使您的代码听起来对业务事务来说是脑死亡，但所有事务性数据库都有可能在发生错误或失败时执行隐式回滚。我觉得这个讨论超出了你的理解力。

如果您遇到了锁定问题，请实现版本控制并清理代码。

没有锁不仅返回错误的值，还返回虚记录和副本。

这是一个常见的误解，它总是使查询运行得更快。如果表上没有写锁，也没有什么区别。如果表上有锁，它可能会使查询更快，但最初发明锁是有原因的。

公平地说，这里有两个特殊的场景，nolock提示可以提供实用程序

1) 2005年以前的sql server数据库需要对实时OLTP数据库运行长查询，这可能是唯一的方法

2)写得很糟糕的应用程序，它锁定记录并将控制权返回给UI和阅读器，无限期地阻塞。如果应用程序无法修复(第三方等)，数据库是2005年以前或版本无法打开，Nolock可以在这里提供帮助。

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

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

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