Sql server 2008 使用NOLOCK提示避免死锁

偶尔，我会在生产环境中遇到以下错误，再次运行相同的存储过程时，这些错误就会消失

事务（进程ID 86）在另一个进程的锁资源上被死锁，并被选为死锁牺牲品。重新运行事务

---

有人告诉我，如果我在存储过程中使用NOLOCK hint，它将确保它永远不会死锁。这是正确的吗？有没有更好的方法来处理这个错误？

虽然添加NOLOCK可以防止读者和作者相互阻塞（更不用说它的所有负面影响），但它并不是解决死锁的神奇方法。许多死锁与读取数据无关，因此将NOLOCK应用于读取查询可能根本不会导致任何更改。您是否运行了跟踪并检查了死锁图以查看死锁到底是什么？这至少应该让您知道要查看代码的哪一部分。例如，存储过程是因为被多个用户同时调用而死锁，还是因为使用了不同的代码而死锁？

RDBMS上偶尔会出现死锁，这种死锁与SQL Server/Sybase类似

您可以根据我的建议在客户端上编写代码以重试。 基本上，检查SQLException，半秒钟后再试一次

否则，您应该检查代码，以便对表的所有访问顺序相同。或者您可以使用设置死锁优先级来控制谁成为受害者

在SQL Server的MSDN上，有一个

尽管僵局无法完全避免

这还提到了“使用较低的隔离级别”，这是我不喜欢的（和这里的许多SQL类型一样），这是您的问题。不要这样做，答案是…：-）

---

注意：类型RDBMS（Oracle、Postgres）没有这个问题。请参见但。出于上述原因，我总是尽量避免使用nolock。另外，您可能希望更好地理解。

NOLOCK对数据库写入（插入、更新、删除）没有影响。理解。然而，我的观点是，在默认隔离级别下等待读卡器完成时，写入程序可能会被阻止。（对不起，我不确定你是在证实我说的话，还是在反驳：-）只是对同一段中使用“NOLOCK”和“Magic fix”的下意识反应。我确信你知道它是如何工作的，我只是想避免一种常见的误解，即NOLOCK可以用来保存bloatin事务日志文件中的插入和更新。如果你，A）使用读提交快照消除读锁，B）确保每个update/delete语句以相同的顺序（可能是字母顺序）获取锁？问题是实现这种逻辑很难还是不值得？（我还没有试过，但我正在考虑，因为我自己也遇到了僵局）