如何证明NOLOCK是死锁问题的根源？

我不是要开始Windows / Mac类型的讨论。

就个人而言，我不需要任何令人信服NOLOCK的自反练习。似乎当您开发所有内容时，应该是有目的的，而不是反动的（/ amen）

所以...主管程序员坚持NOLOCK是要走的路。建议所有临时查询以及每次查询生产时使用。我还没有看到在每个表上都没有nolock提示的存储过程。

不想成为一个进来告诉所有人核心信念的家伙，没有任何支持的想法是错误的。

仅查看各个博客文章下的评论会话，发送链接可能还不够。长期存在的信念等...有些人不相信这是一个问题。请参阅：我阅读的每篇nolock博客文章下的“评论”部分。

当前，其他一些DBA正在努力解决一些神秘的僵局。如何确定NOLOCKs是否为源？

建议从跟踪等中查看XML，但这不会明确指出死锁是导致问题的原因，不是吗？我从未见过如此直接的错误消息。真的吗？

这些僵局又如何能寄托于此？

像DDL语句CREATE将是一个线索。在发出警报之前，是否可以指向任何输出或可以找到的一些数据可以佐证我的理论？

还是我正在运行跟踪标志或扩展事件，以识别发生死锁然后从DDL语句推论得出的结果？

纵观各种数据可能被Nolock提示弄得一团糟，果断地确定销路似乎是一个难题。

负责建筑师如何坚持NOLOCK是要走的路。建议所有临时查询以及每次查询生产时使用。我没有在每个表上都看到没有nolock提示的存储过程。

很抱歉听到这个消息。这在SQL Server专业从业人员中被普遍认为是一种反模式，但是，如果真正根深蒂固，并且基于一个人的真诚和根深蒂固的信念，那么您可能无能为力地改变事实。 。

这个问题说“发送链接可能还不够”，但是不清楚您想要什么。我们可以在此处的答案中写出世界上最引人注目的论点，而您仍然会被“发送链接”。最终，这里没有人会知道在您的特定情况下（如果有的话）哪一组参数将是成功的。

但是，以下内容涵盖了一些人认为足以改变以前的普遍做法的大多数要点：

• 不良习惯：NOLOCK Aaron Bertrand 随处可见
• SQL Server NOLOCK提示和其他不良想法作者：David Lean（Microsoft）
• 读取未提交的隔离级别由我
• 在每个查询中不使用（nolock）提示来证明其合理性（此处是相关的问答）

即使这样，您也可能无法“赢得”这场战斗。我在这样的环境中工作，了解不这样做的风险和原因，但无论如何都会继续这样做。这些人都是聪明，有逻辑的人，但最后我无法在其中工作。

当前，其他一些DBA正在努力解决一些神秘的僵局。如何确定NOLOCKs其来源。

NOLOCK为了减少死锁的发生，引入了更常见的模式（也许在过去更流行）。这可以“起作用”，因为减少采用的共享锁的数量自然会减少采用不兼容的锁的机会，但这并不是解决潜在问题的好方法，并且附带了上一节中提到的所有警告。

但是，NOLOCK提示可以引入新的僵局方式。使用读取未提交隔离可以将瞬态阻塞条件（在争用资源可用时解决）消除为无法解决的死锁（两个服务员都无法取得进展），这仅仅是因为争用现在发生在不同的点，例如以不同的顺序进行写操作交叠。Dave Ballantyne的示例如下：

• 越来越多的僵局 NOLOCK

有关处理死锁的更多一般建议，我建议从以下内容开始：

• 死锁的难度耶利米Peschka

您还应该熟悉文档：

• 死锁（以及那里的所有三个子主题）

其他有用的资源：

• SQL Server死锁示例（由Gail Shaw提供）
• Bart Duncan进行死锁故障排除