sys.sp_reset_connection。為什麼有很多？
DBA EXCHANGE 上有很多問題。但他們都不能幫助我。
我有兩個問題：
**1）**使用
sp_whoisactive，我發現了很多sys.sp_reset_connection;1（我知道它們是sp_reset_connections因為我使用了dbcc inputbuffer（SPID）：
這是“主伺服器”，所以其他伺服器（ 3,4,7 ）在這裡不斷地請求一些數據庫的資訊（我看到的是，每個請求都是針對 MASTER 數據庫的）。
**2)**為什麼他們要花這麼多時間？
看了這裡的一些答案，發現系統正在等待CPU。但所有 CPU 都是空的。這怎麼可能是問題？
在幕後 SQL Server 使用 sp_reset_connection 邏輯來“重置”SQL Server 的連接狀態，這比建立一個全新的連接要快。較舊的驅動程序將過程呼叫作為單獨的 TDS 往返發送到 SQL Server。
較新的客戶端驅動程序在下一個命令中添加了一個標誌位，從而避免了額外的網路往返。
很好……但我還是不知道該怎麼辦。
這不會給我帶來問題。我只想知道如何解決這個問題。
如果沒有性能問題，您可能會忽略所看到的內容。請參閱Bob Dorr - Principal SQL Server Escalation Engineer的 sp_reset_connection – Rate Usage（不要為葡萄爭吵），重點如下：
在幕後 SQL Server 使用 sp_reset_connection 邏輯來“重置”SQL Server 的連接狀態，這比建立一個全新的連接要快。較舊的驅動程序將過程呼叫作為單獨的 TDS 往返發送到 SQL Server。較新的客戶端驅動程序在下一個命令中添加了一個標誌位，從而避免了額外的網路往返。
討論很快轉向：“我的伺服器上 sp_reset_connections 的合理速率是多少？” 像往常一樣，答案總是視情況而定。
沒有硬性規定，但使用性能監視器可以快速將整體批處理率與重置連接率進行比較。當我看到該比率開始攀升至 15% 以上時，這是一個很好的跡象，表明該應用程序可能需要重新審視和調整一下。
綜上所述，您需要小心不要將比率擴展得太遠。在不需要時保持連接將使用更多的客戶端和 SQL Server 成本來增加連接的總數。您需要找到優化客戶端和 SQL Server 資源並最大化應用程序性能能力的最佳點。
您還可以考慮最近的更改，以減少 SQL Server 上 sp_reset_connection 的成本
Dan Guzman also commented:
sp_reset_connection通常不超過幾毫秒（通常是微秒）。例外情況是需要回滾時，因為連接已通過打開的事務返回到池中。我懷疑當您執行時DBCC INPUTBUFFER，它是執行的最後一個命令，而不是需要很長時間的命令。