sql - NOLOCK(Sql Server 提示)是不好的做法吗？

Question

我从事的业务是制作非关键任务的网站和应用程序 -> 例如。银行软件、太空飞行、重症监护监控应用程序等。您懂的。

那么，有了如此大量的免责声明，在某些 Sql 语句中使用 NOLOCK 提示是否不好？几年前，一位 Sql 管理员同事建议，如果我对“脏读”感到满意，我应该使用 NOLOCK，这会给我的系统带来更多的性能，因为每次读取都不会锁定表/行/任何内容。

我还被告知，如果我遇到死锁，这是一个很好的解决方案。因此，我开始遵循这个想法几年，直到一位 Sql 大师帮助我处理一些随机代码，并注意到我的 sql 代码中的所有 NOLOCK。我被礼貌地斥责了，他试图向我解释(为什么这不是一件好事)，但我有点迷失了。我觉得他的解释的本质是“这是一个更严重问题的创可贴解决方案……特别是当你遇到僵局时”。因此，解决问题的根源'。

我最近做了一些谷歌搜索，发现了 this post .

那么，请一些sql db大师老师赐教一下吗？

Answer 1

在从事 Stack Overflow 工作之前，我反对 NOLOCK原则上您可能会执行 SELECT与 NOLOCK并获取可能已过时或不一致的数据的结果。需要考虑的一个因素是，在另一个进程可能从同一个表中选择数据的同时，可以插入/更新多少条记录。如果这种情况经常发生，那么很可能会出现死锁，除非您使用数据库模式，例如 READ COMMITED SNAPSHOT .

此后我改变了对 NOLOCK 的使用看法在见证了它如何改进之后SELECT性能并消除大负载 SQL Server 上的死锁。有时，您可能并不关心您的数据并未完全 100% 提交，并且您需要快速返回结果，即使它们可能已经过时。

在考虑使用NOLOCK时问自己一个问题:

Does my query include a table that has a high number of INSERT/UPDATE commands and do I care if the data returned from a query may be missing these changes at a given moment?

如果答案是否定的，则使用 NOLOCK以提高性能。

<小时/>我刚刚快速搜索了 NOLOCK Stack Overflow 代码库中的关键字，发现了 138 个实例，因此我们在很多地方都使用了它。