NOLOCK 提示会减慢操作吗？

Posted 2023-04-13

【中文标题】NOLOCK 提示会减慢操作吗？

【英文标题】：Does NOLOCK hint slow down operation?

【发布时间】：2016-03-04 17:29:25

【问题描述】：

我对@9​​87654323@ 的使用有疑问。

我知道NOLOCK 提示并不总是最好的方法，但在某些情况下它非常有用。我并不是要养成一直使用它的坏习惯

我只是想了解它的确切行为。有一个不切实际的假设，即更新记录的进程 id = 10 UPDATE table1 SET status = 2 WHERE id = 10 需要 30 秒才能更新。同时我执行SELECT * FROM table1 WITH NOLOCK where id = 10

即使我的第一个查询在记录上具有排他锁，我的 select 语句是否会读取该行，还是我的 select 查询会等到记录上没有任何锁才允许读取？

我想知道使用NOLOCK 是否会导致延迟。

【问题讨论】：

Effect of NOLOCK hint in SELECT statements的可能重复

相反，它可能会运行得更快一些，因为它不必担心锁。是的，您的选择查询将读取该行......大部分时间。它可能会错过它，甚至可能会被退回两次。看看这篇文章。 blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere 它旨在引导人们远离使用该提示，但它也有很多非常有价值的信息。如果您认为您需要阅读它，以便了解该提示的真正作用。

SELECT 可能会或可能不会读取该行。这称为脏读，这样的行可能会被读取零次、一次或两次。我注意到 Sean 的评论引用了 Aaron Bertrand 的关于这个主题的博客（我正要自己引用）。我第二次鼓励你阅读它。

select 可能会错过该行或可能会读取两次。您似乎没有意识到nolock 是什么。我建议您停止使用它，无论您觉得它“在某些情况下有帮助”。

而不是NOLOCK，使用READ COMMITTED SNAPSHOT 或SNAPSHOT 隔离级别。 SELECT 语句在使用这些隔离级别时不会请求锁定，它们会返回一致的结果。

【参考方案1】：

对上述问题的简短回答是：“不。”

在大多数情况下，NOLOCK 提示将加速相关查询，以及同时针对指定表操作的任何其他查询。原因是没有检查或获取锁。您已经在问题中列出了可能的副作用，所以我不会在这里讨论。

最终查询会更快，但结果会令人怀疑。

【讨论】：

人们总是说诸如“结果将是可疑的”或“您不能相信从 NOLOCK 查询返回的数据”之类的话。但唯一一次甚至会成为问题的是，如果有人在查询的同时写入 RELEVANT 数据。在这种情况下，如果您提前 10 秒运行查询，则无论是否使用 NOLOCK，您都会得到与 10 秒后运行查询不同的结果。如果您的结果必须准确到多行数据会导致问题的程度，并且您正在从当前正在写入的表中读取数据，那么您首先做错了。