如何优化SQL存储过程连接池使用_提升并发存储过程吞吐

连接未释放导致连接池耗尽是根本原因。需确保 SqlConnection 均用 using 包裹、禁用存储过程内嵌套连接、确认连接字符串含 Poolingtrue、优化长执行存储过程。存储过程调用时连接没释放导致池子被占满常见现象是并发稍高就报 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool但数据库服务器本身压力不大。本质不是连接池太小而是连接没归还——多数因为存储过程执行完没显式关闭 SqlConnection或用了 using 却在其中抛了未捕获异常导致 Dispose() 没走完。确保所有 SqlConnection 实例都包裹在 using 块里哪怕只做一次查询避免在 using 外部保留对 SqlConnection 的引用比如赋值给类字段检查是否手动调用了 Open() 但忘了 Close()Close() 和 Dispose() 在 ADO.NET 中等效但依赖 using 更安全如果用了 Dapper 或 EF Core确认没绕过其连接管理机制例如直接从 DbContext.Database.GetDbConnection() 拿连接后自行操作存储过程中嵌套打开新连接连接内开连接典型错误是在 SQL Server 存储过程里用 OPENROWSET、OPENDATASOURCE或更隐蔽的在 .NET 层调用一个存储过程该过程内部又通过 SqlDataAdapter 或 SqlCommand 执行另一段 SQL —— 这会额外占用一个池连接且不共享原连接上下文。禁止在存储过程内发起外部数据库访问跨库操作改用视图、同义词或应用层聚合如果必须多数据源协作把逻辑拆到应用层用单个 SqlConnection 分批处理或启用 MARSMultiple Active Result Sets但仅限必要场景检查 ORM 配置如 Entity Framework 的 DbContext 是否被重复构造例如每次调用都 new 一个造成隐式新开连接连接字符串中 Poolingtrue 被意外关掉有些部署环境尤其是容器化或 CI/CD 流水线会动态拼接连接字符串一不留神把 Poolingfalse 写死进去或者漏掉 Poolingtrue默认是 true但显式声明更稳妥。后果是每次调用都新建物理连接TCP 握手登录认证耗时陡增吞吐直接腰斩。 VWO 一个A/B测试工具