SQL Server Profiler - 評估讀取。什麼被認爲是「好」還是「壞」？

Question

我正在分析（SQL Server 2008）的一些視圖和查詢，以確定它們的CPU使用率和讀取效率。我明白Reads是8KB頁面中邏輯磁盤讀取次數。但是我很難確定我應該滿意的。

例如，當我查詢其中一個視圖，該視圖依次與另一個視圖連接並具有三個帶有表值UDF的OUTER APPLY時，我得到的讀值爲321，CPU值爲0.我的第一個想法是我應該對此感到高興。但我如何評估321的價值？這告訴我2654208字節的數據被邏輯讀取以滿足查詢（返回單行和30列）。

你們會如何去決定這是否足夠好，或者需要更多的微調？你會使用什麼標準？

此外，我很好奇什麼是包含在2,654,208字節的邏輯數據讀取。這是否包括返回的單行中的30列中包含的所有數據？

Answer 1

2.5MB包含了321頁中的所有數據，包括與爲查詢檢索的頁面相同的頁面中的其他行，以及爲檢索數據而檢索到的索引頁。請注意，這些是邏輯讀取，而不是物理讀取，例如從緩存頁面讀取會使讀取更「便宜」 - 優化時還需要CPU和分析器成本指標。

w.r.t.如何確定讀取的最佳「目標」。

FWIW我將實際讀數與最佳值進行比較，我認爲這是在「完美」世界中返回查詢中所需數據所需的最小頁數。

例如如果您從表x中每頁計算大約5行，並且您的查詢返回20行，則「完美」讀取次數將爲4，再加上一些導航索引的開銷（假設當然行的聚集「完美」查詢） - 所以烏托邦會在5-10頁左右。

對於性能關鍵查詢，可以使用實際的讀取VS「烏托邦」讀取到微優化，例如：

• 是否我所用的簇（表）適合每頁更多的行，例如用varchar（）不用char替換未被搜索的字符串，或用varchar不用nvarchar（）或用較小的整數類型等。
• 是否可以改變聚集索引，以便需要獲取更少的頁面（例如，如果20上述查詢的行分散在不同的頁面上，然後讀取將會是> 4）
• 如果失敗（因爲您只能有一個配置項），覆蓋索引是否可以替代需要轉到表數據（羣集）由於覆蓋索引適合您的查詢將有更高的「行」密度
• 而對於指數，密度的改進，如填充因子或窄索引的索引可能意味着更少的索引讀

您可能會發現this article有用

HTH！

Answer 2

321讀取CPU值爲0聽起來不錯，但這一切都取決於。

此查詢運行的頻率如何？爲什麼使用表返回的UDF而不是僅僅進行聯接？數據庫使用的上下文是什麼（有多少用戶，每秒事務數量，數據庫大小，是OLTP還是數據倉庫）？

額外的數據讀取來自：

• 在滿足讀取執行計劃完成所需的頁面的所有其他數據。請注意，這包括聚簇索引和非聚簇索引。檢查執行計劃可以讓你更清楚地知道究竟在讀什麼。您將看到對各種索引和表格的引用，以及是否需要查找或掃描。請注意，掃描意味着讀取了整個索引或表中的每個頁面。這就是爲什麼尋求掃描是可取的。

• INNER表中的所有相關數據連接到視圖中，無論這些JOIN是否需要爲您正在執行的查詢提供正確的結果，因爲優化程序不知道這些INNER JOIN將會或獲勝排除/包含行直到它加入它們。

如果您按要求提供查詢和執行計劃，我可能會給你更好的建議。由於您使用的是表值UDF，因此我還需要查看UDF本身或至少UDF的執行計劃（這可能是通過撕掉其肉並在函數上下文外部運行，或者將其轉換爲存儲過程）。