证明在每个查询中不使用 (nolock) 提示

Question

您是否曾经不得不证明不使用查询提示是合理的？

我WITH (NOLOCK)在每个访问非常繁忙的服务器的查询中都看到了。开发人员认为它应该默认开启，因为他们讨厌在他们的代码中看到它数千次。

我试图解释说它允许脏读，最终它们会得到坏数据，但他们认为性能权衡是值得的。（他们的数据库一团糟；难怪他们有性能问题。）

如果你有一个明确的例子来说明如何反对这种滥用NOLOCK提示的情况，那将不胜感激。

Answer 1

你选择你的战斗，像这样的战斗不容易赢得。我们有一个系统，其中每个 DML 都使用 ROWLOCK 提示进行提示（无论修改一行还是几千行）。我展示了几个示例，说明为什么它确实会损害性能，但由于系统已经在运行，因此很难改变。请注意，我已经足够说服他们不要继续使用它。

NOLOCK 有它的地方，但我可以推荐一些很好的参考资料，展示使用它的麻烦：

• Microsoft SQL Server 开发客户咨询团队博客 –如果使用 NOLOCK 提示，可能会丢失先前提交的行
• SQL Magazine 上的 Itzik Ben Gan –聚集索引扫描第三部分
• sqlpass.org 上的 Itkiz Ben Gan –注意 NOLOCK 提示

Answer 2

之前已经在 SO 上讨论过：

• /sf/ask/149877311/#2141802
• /sf/ask/117756831/​​an-happen-as-a-result-of-using-nolock-on-every-select-in-sql-sever

定义很忙。我们有大量数据（每秒 5 万行新行、大型聚合等），并且也不需要获取可疑数据

Answer 3

您必须向您的同事解释了解隔离级别的重要性。给他们看例子。我在 Little Kendra 的隔离级别海报上找到的最好和最简单的解释。问他们为什么认为他们需要 nolock 提示。他们为什么不使用“设置事务隔离级别...”语句？询问他们想要修复的究竟是什么情况，也许他们有死锁、阻塞等。如果他们只是不想持有锁，他们可能会考虑快照隔离级别。

只有问他们你才能有一个清晰的画面。