当你可以接受“脏”数据时使用nolock。这意味着nolock也可以读取正在修改的数据和/或未提交的数据。

在高事务处理环境中使用它通常不是一个好主意，这就是为什么它不是查询的默认选项。

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

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

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

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

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

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

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

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

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

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