使用async访问SQL Server时SqlClient连接池耗尽问题求解

• 同步模式下天然存在被动限流：ASP.NET Core线程池初始线程数极少，冷启动阶段每秒仅能新增2~3个工作线程，即便请求队列堆了数万个请求，同一时间能执行到数据库访问逻辑的请求最多只有几十个，不会打满数据库连接池。
• async模式取消了线程阻塞，等于直接撤掉了线程池这层被动限流：请求进来后无需阻塞等待线程，瞬间就能全部执行到获取数据库连接的步骤，直接把连接池打满，后续请求只能排队等连接，等超时就抛出你遇到的错误。
• 不存在连接未及时归还的问题：你转储里看到的200个正在运行的查询就是连接池满负载的状态，每个查询跑完都会立刻归还连接，但洪峰的请求量远大于连接池的处理能力（比如200个连接每秒最多处理2万次查询，如果洪峰是每秒5万请求，等待队列只会越来越长）。

• 配置主动并发限流：用ASP.NET Core内置的并发限流中间件，设置最大并发请求数略小于连接池最大容量，比如连接池设200，并发请求上限设180，多余的请求直接在入口排队，不会冲到数据库连接层。
• 优化代码异步流程：务必把cn.Open()替换为await cn.OpenAsync()，避免同步打开连接时浪费线程资源，你之前替换后没生效是因为没解决洪峰限流的核心问题。
• 调整线程池最小线程数：在程序启动时调用ThreadPool.SetMinThreads(200, 200)（数值根据你的实际情况调整），避免冷启动阶段线程池扩容慢带来的额外调度延迟。
• 热点查询加缓存：每秒数千次的热点查询优先走内存缓存/分布式缓存，大幅降低落到数据库的实际请求量，从根源上减少连接占用。

• 数据库访问场景完全可以正常使用async，async本身没有问题，还能降低线程开销提升整体吞吐量。
• 高并发场景下不管用不用async都需要限流，只是同步模式下线程池帮你做了被动限流，async模式下你需要主动配置限流规则而已，不需要自己从零实现限流，框架已经有内置的成熟方案。

内容的提问来源于stack exchange，提问作者Alex from Jitbit