我正在 sql server 2019 中进行并发测试，我有运行并发查询的 SQLTest 工具，在我的测试中我使用一个 SELECT 查询（星型模式），在 SSMS 上我有更新事实表记录的 while 循环。在运行这两个进程时，我看到一些线程/查询由于死锁而被取消，这是预期的，但是我正在寻找的选项或者是否有可能在死锁之前在我的选择上添加等待时间？换句话说，SQL 服务器在创建死锁错误之前等待了多少时间。
在这种情况下，我知道不断更新正在发生，但我们知道更新的时间更少，所以如果 SQL 服务器可以在创建死锁之前等待几秒钟。
有什么建议或想法吗？
我建议稍微改变一下你的测试策略。
在您的测试工具中，我会SET DEADLOCK_PRIORITY LOW;这样，当检测到死锁时，您的测试过程会自愿为团队使用一个，允许自己成为死锁的受害者，并允许冲突过程继续。
然后，将测试脚本包装在TRY...CATCH. 在CATCH子句中，检查错误的原因是否是死锁（错误代码 1205），如果是，请重试您的测试。在其中构建一个增量计数器可能是一个好主意，这样您就不会陷入无限死锁循环。
是否有可能在死锁之前在我的选择上添加等待时间？
不，这没有任何意义。
死锁被定义为锁定的死胡同，在任何情况下都不会通过简单的等待来修复。其中一方必须取消。
即 Tx1 已锁定表 a，等待锁定表 b Tx2 已锁定表 b，等待锁定表 a
通常 SQL Server 会等待（超时）并取消。在这种情况下，死锁检测会加强并意识到不，除非一侧被抛出，否则无法解决此问题，因此 - 它取消了一侧。无需等待，因为这实际上是一个编程错误。可不是闹着玩的。
在那里，Tx2 应该首先请求对表 a 的锁定。以定义的顺序在事务中获取锁是一种很好的做法，这样就不会发生这种情况。