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

Question

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

就我个人而言，我不需要任何令人信服的NOLOCK作为反思性练习的好主意。似乎在开发时一切都应该是有目的的而不是反动的 (/amen)

所以......负责程序员坚持NOLOCK是要走的路。推荐所有临时查询和查询生产时。我还没有在每个表上看到没有 nolock 提示的存储过程。

不要成为那种走进来告诉每个人核心信念都是错误的，而没有任何支持的人。

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

目前，其他一些 DBA 正在与一些神秘的僵局搏斗。如何确定 NOLOCK 是否是来源？

有人建议从跟踪等中查看 XML，但这不会明确说明死锁是导致问题的原因，是吗？我从来没有看到过直接的错误消息。真的吗？

否则这些僵局怎么可能被钉在这个上面？

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

或者我是否运行跟踪标志或扩展事件来识别发生死锁时正在运行的内容，然后从 DDL 语句中推断？

看看数据可能被 nolock 提示弄乱的所有不同方式，果断地确定似乎是一个困难的问题。

Answer 1

总建筑师怎么坚持NOLOCK才是王道。推荐所有临时查询和查询生产时。我还没有在每张桌子上看到没有 nolock 提示的 sproc。

很抱歉听到这个。这在 SQL Server 专家从业者中被普遍认为是一种反模式，但如果这种做法真的根深蒂固，并且基于一个人真诚而根深蒂固的信念，那么你可能无法改变实地的事实.

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

尽管如此，以下内容涵盖了大多数人认为足以改变以前普遍做法的观点：

即便如此，你也未必能够‘赢得’这场战斗。我曾在这样做的环境中工作过，了解不这样做的风险和原因，但无论如何还是继续这样做。这些都是聪明、合乎逻辑的人，但最终我无法在这样的环境中工作。

目前，其他一些 DBA 正在与一些神秘的僵局搏斗。如何确定那NOLOCKs是来源。

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

然而，NOLOCK提示可以引入新的死锁方式。使用读未提交隔离可以将暂时阻塞条件（在竞争资源可用时解决）消除为无法解决的死锁（其中两个等待者都无法取得进展），这仅仅是因为争用现在发生在不同的点，例如以不同的顺序写入操作重叠。Dave Ballantyne 有一个例子：

有关处理死锁的更一般性建议，我推荐以下内容作为起点：

您还应该熟悉文档：

其他有用的资源：

“即便如此，你也可能无法‘赢得’这场战斗。我曾在这样的环境中工作过，了解不这样做的风险和原因，但无论如何还是继续这样做。这些人都是聪明、合乎逻辑的人，但最后，这是一个我无法愉快工作的环境。” 这被证明是正确的答案。 (5认同)