.NET API执行耗时数小时的SQL脚本方案咨询

仅异步多线程的局限性 #

直接用你当前的C#异步方法执行1小时级别的长脚本，会遇到几个核心问题：

• 请求超时：GraphQL API、Blazor客户端甚至数据库连接都有默认超时限制（比如Kestrel默认2分钟），即便强行调大超时参数，用户也得长时间等待页面响应，中途网络波动或服务器重启会直接导致任务中断，且无恢复能力。
• 资源占用：API服务器会持续持有数据库连接和线程资源，并发场景下会挤压其他请求的资源，甚至引发服务雪崩。
• 容错缺失：脚本执行中途出错时，没有状态记录和重试机制，用户只能重新提交脚本，还可能留下半完成的数据状态。

推荐的Azure工具方案 #

针对长时间运行的异步任务，Azure的以下服务能从根本上解决上述问题：

1. Azure Queue Storage + Azure Functions #

• 调整流程：GraphQL API收到请求后，将脚本的Blob路径、数据库配置等信息写入Azure队列，立即返回任务ID给Blazor客户端；通过队列触发的Azure Functions读取队列消息，从Blob拉取脚本并执行数据库操作。
• 核心优势：
  • 完全解耦API与执行逻辑，API无需等待脚本完成，瞬间响应用户请求。
  • Functions支持自动伸缩，多脚本并发执行也不会占用API服务器资源。
  • 队列自带重试机制，执行失败可自动重试，异常任务还能转入死信队列统一排查。

2. Azure Logic Apps #

• 无代码/低代码方案：通过Logic Apps搭建工作流，监听Blob上传事件，自动触发SQL脚本执行任务，还能集成邮件、推送服务向用户反馈执行状态。
• 核心优势：无需编写复杂的调度和容错代码，快速实现任务自动化与状态通知。

如果是大规模批量脚本执行场景，可选用Azure Batch专门管理计算节点与任务分配。

现有代码的临时优化方案 #

若暂时不想调整架构，需对现有代码做关键补充：

• 设置超时参数：给DbCommand配置足够长的超时时间，比如command.CommandTimeout = 3600;（对应1小时），同步调大API与Blazor客户端的超时限制。
• 拆分脚本+状态持久化：将长脚本拆分为多个独立步骤，每步执行完成后将状态存入数据库，避免任务中断后需从头执行。
• 实时状态反馈：通过SignalR向Blazor客户端推送执行进度，或让客户端轮询数据库获取状态，提升用户体验。
• 完善取消逻辑：确保CancellationToken在脚本执行的关键步骤生效，支持用户主动取消任务。

总结 #

仅依赖异步多线程无法解决长耗时任务的超时、容错与资源占用问题，优先推荐Azure Queue + Functions的组合方案，实现系统解耦与任务可靠执行；若追求快速搭建工作流，可选择Azure Logic Apps。现有代码仅能作为临时方案，必须配合状态管理与超时配置才能勉强运行。

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