【发布时间】:2016-03-04 17:29:25
【问题描述】:
我对@987654323@ 的使用有疑问。
我知道NOLOCK 提示并不总是最好的方法,但在某些情况下它非常有用。我并不是要养成一直使用它的坏习惯
我只是想了解它的确切行为。有一个不切实际的假设,即更新记录的进程 id = 10 UPDATE table1 SET status = 2 WHERE id = 10 需要 30 秒才能更新。同时我执行SELECT * FROM table1 WITH NOLOCK where id = 10
即使我的第一个查询在记录上具有排他锁,我的 select 语句是否会读取该行,还是我的 select 查询会等到记录上没有任何锁才允许读取?
我想知道使用NOLOCK 是否会导致延迟。
【问题讨论】:
-
相反,它可能会运行得更快一些,因为它不必担心锁。是的,您的选择查询将读取该行......大部分时间。它可能会错过它,甚至可能会被退回两次。看看这篇文章。 blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere 它旨在引导人们远离使用该提示,但它也有很多非常有价值的信息。如果您认为您需要阅读它,以便了解该提示的真正作用。
-
SELECT可能会或可能不会读取该行。这称为脏读,这样的行可能会被读取零次、一次或两次。我注意到 Sean 的评论引用了 Aaron Bertrand 的关于这个主题的博客(我正要自己引用)。我第二次鼓励你阅读它。 -
select可能会错过该行或可能会读取两次。您似乎没有意识到nolock是什么。我建议您停止使用它,无论您觉得它“在某些情况下有帮助”。 -
而不是
NOLOCK,使用READ COMMITTED SNAPSHOT或SNAPSHOT隔离级别。SELECT语句在使用这些隔离级别时不会请求锁定,它们会返回一致的结果。
标签: sql sql-server locking nolock