SQL Server 超时 - 重试或更长的超时？答案

【问题标题】：SQL Server Timeouts - retries or longer timeouts?SQL Server 超时 - 重试或更长的超时？
【发布时间】：2019-10-21 10:32:16
【问题描述】：

我有一个由于 SQL Server 超时而失败的 UPDATE 命令。这是一个用于存储事件的大表，主键是一个非聚集索引（无论如何都不重要，因为它是一个 uniqueidentifier 列）。

它正在更新一行：update [table] set [field] = 1 where [primary_key] = [primary_key_value];。问题可能在于有超过 200,000,000 行，因此查找每一行需要很长时间。

就 SQL Server 的偏好而言，我最好增加命令超时时间（是的，我知道默认的 30 秒已经是任何合理查询的 30 倍），或者我应该引入一个 更短的 超时，但一遍又一遍地重试（达到极限）？

那么 60 秒的命令超时是否比 5 秒超时的 6 次重试更好？

在实践中，当然会有某种指数退避和断路器实现。

【问题讨论】：

【解决方案1】：

评论有点长。

只有当超时的原因是资源争用时，重试才会有所帮助。在这种情况下，您最好使用某种指数退避，而不是立即运行查询。

但是，我推测原因是由于以下任一原因：

如果行数是问题，您可以将update 限制为例如 100 行，然后重复更新直到全部完成。不过，我会先调查查询，看看是否可以通过其他方式对其进行优化。

【讨论】：

这是单行。 update [table] set [field] = 1 where [primary_key] = [primary_key_value];。问题很可能是有超过 200,000,000 行，因此需要很长时间才能找到每一行。关于后退的好点。我应该提到后退和断路器可能是我采用的实际解决方案。我只是想知道重试是否比一般更长的超时更好。
@NeilBarnwell。 . .如果您使用主键索引，基本上不需要时间来查找单行。好吧，确实需要一些时间。加载索引可能需要时间。但除非您处于内存严重受限的环境中，否则主键索引可能已经完全在内存中。
@NeilBarnwell。 . .从系统的角度来看，我认为最好的方法是多次较短的超时。这可以减轻系统负载并释放资源，从而消除瓶颈。这是一般原则，不仅适用于数据库。