我已经读过这个死锁问题当数据库表开始累积数千行并且许多用户同时开始在同一个表上工作时，对表的SELECT查询开始产生锁争用和事务死锁。
这个死锁问题是否与TransactNo updlock有关？ 如果你知道这个问题，请告诉我。 提前致谢。
答案 0 :(得分：8)
死锁可能由于多种原因而发生，有时对死锁进行故障排除可能更像是一门艺术而非科学。
我用来查找和删除死锁，在纯SQL Profiler之外，是一个轻量级工具，可以在出现死锁时提供图形描述。当您看到死锁时，您可以深入了解并获取有价值的信息。死锁检测器 - http://www.sqlsolutions.com/products/sql-deadlock-detector
这是一个简单的工具，但对我来说，它确实完成了应该做的事情。有一件事：我第一次使用它时，我不得不等待15分钟才能收集足够的指标来开始显示死锁。
答案 1 :(得分：4)
死锁可能由于很多原因而发生，所以如果你想得到帮助并告诉我们导致死锁的原因，你必须先做一些功课。什么是批处理涉及执行死锁，涉及什么资源等等。 Profiler deadlock event graph始终是开始调查的好地方。
如果我在黑暗中冒风险，那么你的查询和索引没有正确调整，因此你的大多数读操作（也许是一些写操作）都是全表扫描，因此保证与之冲突更新。这可能导致deadlocks by order of index access，操作顺序死锁，升级死锁等等。
一旦确定了死锁原因，就可以采取适当的措施将其删除。他采取适当行动采取肮脏阅读的案件非常罕见。
BTW我不确定你的'TransactNo updlock'是什么意思。您是否具体询问S-U/U-S asymmetry of the U locks？
答案 2 :(得分：4)
由于以下情况，高隔离度的常见问题是锁定升级死锁;即（其中X是任何资源，例如行）
死锁！通过 more lock可以避免这种情况：
(UPDLOCK)的读取X - 获取独占锁答案 3 :(得分：3)
您没有提供足够的信息来直接回答您的问题。
但是，通过使用“正确”索引来覆盖查询工作负载，可以减少（甚至消除）大多数锁定和阻塞。
您是否安排了常规的索引维护工作？
如果SELECT不需要100％准确（即允许脏读等），那么您可以使用SELECTS运行一些WITH(NOLOCK)，这与{1}}相同隔离级别为READ UNCOMMITED。请注意：我不建议您到处放置WITH(NOLOCK);只是那些不需要100％完整数据的SELECTS。
答案 4 :(得分：3)
我会把我自己的文章和帖子放到关于死锁的混合中：
https://www.sqlskills.com/blogs/jonathan/category/deadlock/
我还有一系列关于JumpstartTv.com上的死锁问题的视频：
http://jumpstarttv.com/profiles/1379/Jonathan-Kehayias.aspx
死锁可能难以解决，但除非您发布死锁图信息，否则我们无法提供更多信息，只需提供有关解决死锁的帖子和信息的链接。
答案 5 :(得分：1)