SQL命令及连接已配超时时使用Polly超时策略的收益问询

SQL自带的超时配置和Polly超时策略不是替代关系，两者覆盖的边界完全不同，Polly超时在多数生产场景下有明确的实际收益，核心差异如下：

• 覆盖范围差异
  • 连接字符串配置的Connection Timeout仅对connection.OpenAsync()建立数据库连接的过程生效，连接建立完成后该配置不再起作用。
  • SqlCommand.CommandTimeout仅约束命令执行阶段的耗时，即从发送请求到数据库返回第一批结果的时间窗口，无法覆盖执行完成后的结果读取、对象映射等后续流程。比如你代码中ExecuteReaderAsync之后的mapper.Map映射逻辑，如果遇到大结果集、映射逻辑复杂导致长时间阻塞，CommandTimeout完全不会触发，会持续占用工作线程和数据库连接，最终拖垮服务吞吐量。
  • Polly超时策略包裹的是整个执行委托的全链路，从获取连接字符串、建立连接、执行命令、读取结果到对象映射的全流程都会受超时阈值约束，不会出现非SQL执行阶段卡死导致的资源泄漏。
• 重试配合的灵活度差异
  你当前代码中使用retryPolicy.WrapAsync(timeoutPerTry)的写法，实现的是「每次重试独立应用超时规则」的效果，这是SQL原生超时很难低成本实现的：
  • 你代码注释中提到的「每次重试放大超时时间」的动态规则，如果仅靠CommandTimeout实现，需要手动在重试回调中维护状态、传递变量，很容易写出闭包变量并发污染的问题——你当前代码中用闭包共享变量taskTimeoutInSeconds给CommandTimeout赋值的写法，在高并发下就会出现不同请求的超时值互相覆盖的bug。Polly原生支持通过Context在单次执行/重试的生命周期内传递参数，不需要自己维护共享变量。
  • 原生超时无法控制重试链路的总耗时：如果单次CommandTimeout设为30秒，最大重试5次，最坏场景下整个执行流程会耗时150秒以上，很容易耗尽上游调用方的等待时间。通过Polly策略嵌套，你可以在重试策略外层再加一层总超时策略，直接约束整个操作（包含所有重试）的最大允许耗时，避免请求长时间堆积。
• 异常处理的归一化收益
  仅用SQL原生超时的话，你需要单独捕获连接阶段超时、命令执行阶段超时、后续流程超时等不同场景下的不同异常类型，甚至要像你现在写的这样判断SqlException的Number值来识别超时。全链路接入Polly超时后，所有环节的超时都会统一抛出TimeoutRejectedException，异常捕获和处理逻辑会更简洁清晰。

什么场景下可以去掉Polly超时？ #

如果你能同时满足以下所有条件，确实可以只保留Polly重试策略，去掉独立的超时策略，简化代码：

• 业务查询的结果集很小，数据映射逻辑非常简单，不存在结果读取、对象映射阶段长时间阻塞的风险
• 不需要动态调整每次重试的超时阈值，也不需要约束包含重试在内的整个操作的总耗时
• 可以接受不同环节抛出不同类型的超时异常，单独维护对应的捕获处理逻辑

你当前代码的注意点 #

你目前使用的是TimeoutStrategy.Optimistic乐观超时模式，该模式要求执行委托主动接收Polly传入的CancellationToken，并将其透传给OpenAsync、ExecuteReaderAsync等支持取消的异步方法，否则超时触发后只能放弃等待任务结果，无法真正中断后台正在执行的SQL操作，会导致连接资源被无效占用。如果要让超时真正生效，需要把CancellationToken逐层传递到所有异步调用中。

内容的提问来源于stack exchange，提问作者daxu