我试着读一篇关于锁和死锁的文章，它只是不着陆，不同类型的锁。 我们正在运行2个不同的进程，它们试图编辑同一个表中的记录。 第一个进程读取新数据并将其发送给外部方并相应地更新状态，另一个进程接收来自外部方的接收结果并相应地更新状态。有没有一种方法来防止死锁（以及发生了什么是一个发生，一个受害）
现在我们越来越多的死锁（在这种情况下，其中一个是victom并被中止）。到目前为止这么好，因为你可以预见到这一点，并尝试重新运行该声明，但总是发生同样的死锁。这就是我的第一个问题：为什么同样的死锁总是再次发生？
第二，有没有办法告诉dbms，当另一个进程正在读取和更新记录时，不要尝试获取记录的独占锁（我们通过存储过程更新单个记录），而是'等待一边'直到另一个进程准备好了？或者说是一个太简单的事情来说死锁？
并且可能是第三个，有没有办法向LINQ to SQL询问哪些锁导致了问题，所以我对该进程的哪些部分导致问题有所了解。
正如@Darryl Peterson所指出的，SQL Profiler是捕获死锁信息的好工具。如果您不知道何时会发生死锁，则可以设置SQL Server跟踪标志来捕获数据。
DBCC TRACEON (1204)
当发生死锁时，有关死锁的信息将写入SQL Server错误日志。
有很多方法可以导致死锁。你的第一个问题“为什么总是发生同样的僵局”可能是一个好兆头。如果死锁是可重复的，那么你可以捕捉并修复它。
关于第二个问题，SQL Server可能已经告诉一个进程要等待另一个进程完成。但是，你无法通过等待来避免僵局。死锁是一个进程试图使用另一个进程持有的资源的情况。但另一个进程正在等待第一个进程持有的资源。这两个进程在完成其工作之前都不会释放资源。请注意，这是一个简单的解释，可能会有更复杂的死锁情况。重点是，在死锁过程中将会从永远不能能够完成。
一旦您了解到有关死锁涉及的过程的更多信息，您应该能够采取措施避免它。
SQL事件探查器是我用来开始尝试解决SQL Server中的死锁问题的最佳工具。
开始跟踪： 在事件选择选项卡上： 取消选中所有预选事件。 选中“显示所有事件”。 展开“锁定”。 选中“死锁图形”，“锁定：死锁”和“锁定死锁链”。
运行跟踪并捕获死锁事件。
查看SQL事件探查器中的死锁事件。死锁显示非常好。您可能仍然需要查看原始XML以获取更多详细信息。
使用您从第一遍中发现的内容，可能会提供有关更改内容的建议，或建议在SQL事件探查器中跟踪其他事件。