sql-server - NOLOCK 还是不NOLOCK？

Question

我曾在一个非常大的组织工作，他们必须在大多数查询中使用 NOLOCK - 因为数据通常在白天通过 ETL 过程更新并锁定应用程序 40% 的工作一天当然不是一个选择。

出于习惯，在我的下一个地方，我继续在所有地方自动使用 NOLOCK。但自从阅读警告和风险后，我逐渐撤消了这一点，没有指定表提示，让 SQL Server 来做这件事。

但是，我仍然觉得我做的是对的事。在我们使用 NOLOCK 的地方，我从未见过数据翻倍或损坏数据。我在那里待了很多年。自从删除 NOLOCK 之后，我就遇到了行锁减慢/暂停查询的明显障碍，这给人一种我的数据库很慢或不稳定的错觉。实际上，只是有人在某处运行了一个冗长的保存(他们这样做的能力是应用程序的要求)。

我很想听听任何在实践中实际经历过 NOLOCK 的数据损坏或数据复制的人的意见，而不是那些按照他们在互联网上阅读的内容进行操作的人的意见。如果有人可以提供复制步骤来看到这种情况发生，我将特别感激。我正在尝试评估它的风险有多大，风险是否超过了能够在更新的同时运行报告的明显好处？

Answer 1

我见过 NOLOCK 的损坏、重复和不良结果。不是一次，也不是很少。 每个 依赖于 NOLOCK 的部署，我有机会查看都存在正确性问题。诚然，许多人(大多数？)没有意识到也没有意识到，但问题一直都存在。

您必须意识到 NOLOCK 问题不会表现为硬损坏(DBCC CHECKDB 会报告的那种)，而是“软”损坏。而且这些问题仅在某些类型的工作负载上很明显，主要是在分析类型(聚合)上。它们会表现为报告中的错误值、分类账中的余额不匹配、错误的部门人数等等。这些问题只有在合格人员仔细检查时才会被视为问题。而且它们很可能会在页面的简单刷新时神秘地消失。所以你很可能有所有这些问题，但没有意识到它们。您的用户可能会接受“有时余额有误，只需再次请求报告就可以了”，而不会向您报告该问题。

还有一些工作负载对NOLOCK问题不是很敏感。如果您显示“帖子”和“评论”，您将不会看到太多 NOLOCK 问题。也许“未答复计数”减少了 2，但谁会注意到？

Ever since removing NOLOCK I am running into the obvious obstacle of rowlocks slowing / pausing queries

我建议评估 SNPASHOT 隔离模型(包括 READ_COMMITTED_SNAPSHOT)。你可能会得到免费的午餐。