這種查詢如何在不佔用太多資源的情況下佔用這麼多時間？

我運行了SQL Server Profiler跟蹤（批量完成持續時間）並發現了一個非常長的正在運行的查詢。這些都爲五大運行時間最長的查詢利用統計數據：這種查詢如何在不佔用太多資源的情況下佔用這麼多時間？

Count Duration CPU  Reads Writes 
1  1237757030 608  47979 10 
14695 358668961 355928 4818709 315 
3501 48323496 43705 625474 17 
75883 46373094 45250 8526977 127 
34  35394031 10200 2461621 0

第一個運行速度比第二長近3倍，即使第二個有一個更大的累計CPU時間和數量比第一讀取一。這怎麼可能，或者我怎麼能找到更多關於這裏發生的事情？

來源

2011-11-22 Flo

如果您正在運行SQL分析器，您應該能夠獲取正在運行的原始SQL查詢。如果你能看到那應該提供一個洞察力？如果這樣粘貼到問題中。 – Chris

您可以嘗試查看查詢執行計劃，以更好地瞭解查詢正在做什麼以及爲什麼需要這麼長時間。 – Danny

LongerDuration + LessCPU-LessReads-LessWrites可能來自查詢等待釋放的一個（或多個）鎖。 –

通常這是由某種資源爭奪造成的。換句話說，在等待鎖釋放（阻塞），從磁盤讀取數據，等待線程完成其工作等等時，您的查詢處於空閒狀態。

這是一個很深的問題，但我會建議從看着你的等待統計。

要了解累積等待統計信息，請查看sys.dm_os_wait_stats。來自BOL：

「查詢執行期間的特定類型的等待時間可以指示查詢中的瓶頸或停頓點。同樣，高等待時間，或等待計數服務器級可以在服務器實例中表示在交互詢問，互動的瓶頸或熱點。」

您也可以運行查詢，並試圖找出與阻塞問題。這是一篇關於這個主題的好文章。

http://www.simple-talk.com/sql/sql-tools/how-to-identify-blocking-problems-with-sql-profiler/

這些都是看幾個領域，但老實說，有這麼多的變數，短期訪問您的服務器，這是令人難以置信很難超越報價的猜測和建議任何東西，你可以看看。

來源

2011-11-22 17:09:28

這種查詢如何在不佔用太多資源的情況下佔用這麼多時間？

回答

相關問題