我有一個運行緩慢的查詢，我一直在優化。SQL Server - Management Studio - 客戶端統計信息 - 等待服務器響應時間和客戶端處理時間
在Management Studio中查看客戶端統計信息時，服務器應答等待時間大約爲8秒，客戶端處理時間大約爲1秒。
我一直認爲服務器回覆上的等待時間是要處理的數量，而客戶端處理時間通常是帶寬或與數據大小有關。
我已經對查詢進行了一些更改，現在我在服務器回覆上的等待時間大約爲250毫秒，但是，客戶端處理時間增加到約9秒，總執行時間稍微慢一些。
返回的結果集完全相同。
有人可以澄清這兩個數字之間的區別究竟是什麼以及會導致這樣的結果嗎？
「等待時間對服務器回覆」是最後的請求分組之間的時間離開所述客戶端和所述的第一個響應數據包從返回服務器。 '客戶端處理時間'是第一個響應數據包和最後一個響應數據包之間的時間。順便說一句，我找不到支持這些說法的文檔，但我會說，根據我的觀察，他們是有效的教育猜測。
如果您運行一個查詢，並在服務器應答中等待一段時間，這意味着服務器花費很長時間才能生成第一行。對於那些需要整個子查詢在運行前進行求值的運算符（典型的例子是排序運算符），查詢通常是這樣的。
另一方面，具有非常小的'服務器回覆等待時間'的查詢意味着查詢能夠快速返回第一行。然而，長時間的「客戶端處理時間」並不一定意味着客戶端花費了大量時間處理，並且服務器被阻止在客戶端等待。它可以簡單地表示服務器繼續從結果中返回行，這是直到最後一行返回需要多長時間。
您看到的是查詢計劃中可能移除阻止執行的操作符（最可能是排序）的更改的結果，並且新計劃使用不同的策略來更快地生成第一個結果（可能使用索引保證所要求的訂單，所以我不需要），但整體持續時間更長。
如果你擔心客戶躊躇不前服務器（它可以發生在大型結果集），那麼你應該調查sys.dm_exec_requests的wait_type（也sys.dm_os_tasks和sys.dm_os_workers信息是有用的），用於執行下調查的查詢會話。如果我沒有弄錯，等待客戶端等待類型的服務器是ASYNC_NETWORK_IO。您也可以檢查聚合sys.dm_os_wait_stats，使用DBCC SQLPERF("sys.dm_os_wait_stats" , CLEAR)重置它，然後運行查詢，查看ASYNC_NETWORK_IO等待類型累計了多長時間。當然，在測試期間確保服務器上沒有其他活動發生。
這就是我認爲他們的意義。關鍵是，這兩個查詢仍然具有相同的外部排序順序，並對此類進行更改，以包含未進行索引的列仍會導致相同的輸出。我會看看一些等待類型和網絡io的東西。謝謝。我仍在製作一個測試工具來展示所有這些。希望它會更有意義。 – 2009-12-02 08:11:03
好的，我發現了一些與此主題有關的文章。我希望他們可能會有幫助。我必須說，這爲我打開了關於查詢性能調整的所有新門。
SQL Server Wait Events: Taking the Guesswork out of Performance Profiling
Analysing Query Performance in SQL Server 2005
感謝這些，我會讀一讀。我無法發佈我一直在運行的查詢。它非常大，沒有很多背景就不會產生很多感覺。我正在研究一個簡單的測試工具，可以產生相同的結果。我會盡快發佈。 – 2009-12-01 18:34:14
斷開的鏈接。嘗試http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspx或http://technet.microsoft.com/en-us/library/aa216969(v=sql。 80）.aspx或搜索「查詢窗口統計窗格」 – 2012-11-07 19:43:07
您試圖執行的查詢是什麼？ – 2009-12-01 17:56:29
經過進一步調查後，問題將在查詢中加入到表值UDF中。這導致SOS_SCHEDULER_YIELD 等待查詢的每一行。該表的參數是固定的，所以我只是用它填充一個臨時表並加入到該表中。這兩個答案幫助我，所以選擇一個接受是艱難的。我會把它交給Remus，因爲他確認了我對我兩次看到的想法，並且給出了確切的命令以獲得等待。 – 2009-12-02 12:51:59