相同的查詢計劃，不同的數據集，非常不同的查詢持續時間 SQL Server 2012
這可能是一個可怕的問題，因為我不確定我可以包含哪些資訊來提供幫助。
我們有按客戶分類的數據。一位客戶顯然擁有更多的數據量。對小客戶返回的相同查詢執行了 2 秒，結果為 11 行。較大的客戶需要 47 秒，結果是 6600 行。這是一個包含 11 個連接的複雜查詢。這只是一個報告，但是報告超時並且操作員正在抱怨。差異可能只是數據量，但我想調查一下。
當我查看查詢計劃時，查詢成本的百分比在兩者之間完全相同。沒有關於索引的建議。在這兩個查詢計劃中，我可以看到最高成本是連接到具有 380 萬行的表。但是，兩組數據都與同一個表連接。在這兩種情況下，產生的“實際行數”都是 380 萬。在這兩種情況下，此連接都有一個聚集索引掃描，它是查詢“成本”的 39%。
所以我的問題是：百分比和查詢成本是否意味著什麼？他們是指查詢計劃中的估計數據，而不是反映實際成本嗎？否則，同一個連接怎麼會佔兩者“成本”的 39%，但一個需要 2 秒，一個需要 47 秒？SQL Server 是否對我撒謊，成本的實際差異是產生最終行數的內部連接的“嵌套循環”，即使它將成本列為 0%？
這些圖像顯示了成本最高的兩個元素。它們在兩個查詢計劃之間具有相同的屬性。最後一行總計的差異是與其他表連接的結果。但是這些連接都具有較低的相對成本。
百分比和查詢成本是否意味著什麼？
不是真的——它們有意義，但它們不可靠。
他們是指查詢計劃中的估計數據，而不是反映實際成本嗎？否則，同一個連接怎麼會佔兩者“成本”的 39%，但一個需要 2 秒，一個需要 47 秒？
確切地說——成本是一個估計值。如果您在將滑鼠懸停在操作員上時查看詳細彈出視窗，您會發現您在圖形計劃中看到的“成本”實際上是“估計的操作員成本”。它基於執行前的估計，即使實際成本有所不同，也將是相同的。
SQL Server 是否對我撒謊，成本的實際差異是產生最終行數的內部連接的“嵌套循環”，即使它將成本列為 0%？
這不是說謊，但也不是現實。同樣，由於這些是基於估計的，因此它們可能是錯誤的。特別是，有時您會看到成本百分比加起來超過 100%——這是另一個指標，它不是基於實際性能。
有更好的方法
恕我直言，SQL Sentry Plan Explorer 是查看實際執行性能數據的最簡單方法。它將為您的批處理中的每個語句提供實際的 CPU 和 IO 資訊，您可以使用這些資訊將批處理中最昂貴的部分歸零。在這種情況下，您可以針對不同的客戶測試相同的語句並查看實際執行結果。
您可能還想嘗試
SET STATISTICS IO,TIME ON通過 statisticsparser.com 使用和執行結果。這將使您很好地了解針對不同客戶的兩個查詢之間的 IO/CPU 差異。