在 SQL Server 中增加最大池大小的成本
我們有一個大部分時間執行良好的公共前端網站。但是我們有時會遇到連接高峰（比如在郵寄活動之後），我們會遇到如下錯誤：
超時已過。在從池中獲取連接之前超時時間已過。這可能是因為所有池連接都在使用中並且達到最大池大小
我們非常確定我們所有的連接都已正確關閉（沒有連接洩漏）。
因此我們決定增加池中允許的連接數（預設為 100）。
我們將其增加到 1000（
max pool size=1000;在我們的連接字元串中），現在我們的站點可以處理大多數連接峰值。（我精確地將該站點執行在專用伺服器上）我的問題是：增加最大連接池可能會產生什麼負面影響？
編輯：這是我在這些高峰期間使用 sp_who2 時所擁有的：
如果最大池設置為 100，我有超過 100 行“等待命令”行：
我可以看到所有“LastBatch”都是在幾秒鐘前執行的。
將伺服器的CPU想像成一個餡餅，SQL Server 是一個聚會，連接就是您在聚會上的客人。如果您知道您將有 10 位客人（連接），那麼您需要將餡餅切成 10 等份，以便每個人都能得到公平的一份。
現在想像一下，您有 10 位客人，但意外出現了 10 位客人，因此聚會上共有 20 位客人。好吧，要麼你仍然可以把餡餅切成 10 片，然後一次只能讓 10 位客人吃甜點，或者你可以把這 10 片切成小塊，這樣你現在就有 20 片同樣大小的餡餅，這樣你就可以給每位客人一份切片（例如增加最大池大小）。
所以基本上你允許更多的連接到你的 SQL Server 需要為每個連接分配相當數量的CPU 。使用固定數量的CPU（將擴展雲服務排除在此討論之外），這意味著您的其他連接可用於它們需要執行的查詢的CPU 可能會減少，理論上這可能會使這些查詢需要更長的時間才能完成。其他伺服器資源也可能以類似的方式受到影響（如 nbk 提及），例如記憶體，因為現在更多的連接也將競爭可用記憶體以進行查詢。
這取決於您的應用程序的設計方式以及負載可以達到的繁忙程度，但是增加最大池大小是嘗試解決您面臨的問題的公平解決方案。雖然你可能不想一開始就跳這麼大。也許嘗試將初始設置增加一倍或三倍，然後逐步提高。如果您仍然遇到該錯誤或其他性能問題，那麼您唯一的選擇可能是為您的伺服器提供更多 CPU，查看如何優化應用程序以使其數據庫操作更快、更智能，並查看如果查詢和/或數據庫設計本身有性能優化機會。