我们有一个大部分时间运行良好的公共前端网站。但是我们有时会遇到连接高峰（比如在邮寄活动之后），我们会遇到如下错误：
超时已过。在从池中获取连接之前超时时间已过。这可能是因为所有池连接都在使用中并且达到最大池大小
我们非常确定我们所有的连接都已正确关闭（没有连接泄漏）。
因此我们决定增加池中允许的连接数（默认为 100）。
我们将其增加到 1000（max pool size=1000;在我们的连接字符串中），现在我们的站点可以处理大多数连接峰值。（我精确地将该站点运行在专用服务器上）
我的问题是：增加最大连接池可能会产生什么负面影响？
编辑：这是我在这些高峰期间使用 sp_who2 时所拥有的：
如果最大池设置为 100，我有超过 100 行“等待命令”行：
| SPID | 地位 | 登录 | 主机名 | BlkBy | 数据库名称 | 命令 | CPU时间 | 磁盘IO | 最后一批 | 程序名称 | SPID | 请求ID |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 数字 | 睡眠 | db_user | 我网站的 IIS 池名称 | . | 我的数据库名称 | 等待命令 | 0 | 0 | 05/10 14:48:59 | .Net SqlClient 数据提供者 | 137 | 0 |
我可以看到所有“LastBatch”都是在几秒钟前执行的。
将服务器的CPU想象成一个馅饼，SQL Server 是一个聚会，连接就是您在聚会上的客人。如果您知道您将有 10 位客人（连接），那么您需要将馅饼切成 10 等份，以便每个人都能得到公平的一份。
现在想象一下，您有 10 位客人，但意外出现了 10 位客人，因此聚会上共有 20 位客人。好吧，要么你仍然可以把馅饼切成 10 等份，然后一次只能让 10 位客人吃甜点，或者你可以把这 10 片切小一点，这样你现在就有 20 块同样大小的馅饼，这样你就可以给每位客人一份切片（例如增加最大池大小）。
所以基本上你允许更多的连接到你的 SQL Server 需要为每个连接分配相当数量的CPU 。使用固定数量的CPU（将扩展云服务排除在此讨论之外），这意味着您的其他连接可用于它们需要运行的查询的CPU 可能会减少，理论上这可能会使这些查询需要更长的时间才能完成。其他服务器资源也可能以类似的方式受到影响（如 nbk 提及），例如内存，因为现在更多的连接也将竞争可用内存以进行查询。
这取决于您的应用程序的设计方式以及负载可以达到的繁忙程度，但是增加最大池大小是尝试解决您面临的问题的公平解决方案。虽然你可能不想一开始就跳这么大。也许尝试将初始设置增加一倍或三倍，然后逐步提高。如果您仍然遇到该错误或其他性能问题，那么您唯一的选择可能是为您的服务器提供更多 CPU，查看如何优化应用程序以使其数据库操作更快、更智能，并查看如果查询和/或数据库设计本身有性能优化机会。
如果连接确实在不活跃使用时正确关闭和处理（即立即返回到池中）并且您在应用程序服务器和数据库服务器上都有容量净空，那么我预计较大的池大小不会产生负面影响。但是，根据根本原因，增加最大池大小以避免峰值负载错误可能不是最佳方法。考虑对应用程序和数据库服务器资源的影响。
查询在数据库服务器上大多处于可运行状态吗？这可能表明需要调整查询/索引，或者数据库服务器可以使用更多内核来处理 SLA 内的峰值需求。
服务器端的查询是否主要由于异步网络等待而暂停？这可能是 Web 服务器在负载下消耗查询结果缓慢的症状，表明应用服务器可能需要更多内核、实例或网络带宽。您提到了“专用服务器”，因此可能需要额外的应用程序服务器。请注意，100 个活动查询还需要应用服务器和数据库服务器上的 100 个线程。
服务器端的查询大部分是否由于其他资源等待（例如 IO、锁或闩锁）而暂停？这可以通过查询/索引调整或数据库服务器配置（例如，在 tempdb 页面锁存器争用情况下更多 tempdb 文件）来缓解。