為什麼視窗聚合函數會導致 SQL Server 中如此高的邏輯讀取？

為什麼視窗聚合函數的邏輯讀取量很高？

在執行計劃中使用公共子表達式假脫機時，邏輯讀取往往會顯著增加對於更大的桌子。經過實驗和觀察執行計劃，發現以下公式似乎成立：

工作表邏輯讀取= 1 NumberOfRows 2 NumberOfGroups 4

然而，🎜> 4

然而，🎜>然而，這個公式的根本原因仍不清楚。本文旨在揭開邏輯讀取計算背後的謎團。

理解視窗聚合函數執行

計畫開始時的段迭代器會向行附加一個標誌指示每個新分割區的開始。隨後，主段假脫機每次檢索一行並將它們插入 tempdb 工作表中。遇到新的群組標誌時，假脫機會將一行返回到嵌套循環運算子的上部輸入。

這會觸發工作表行上的流聚合，計算平均值。然後將計算出的平均值與工作表行連接，並截斷工作表以準備下一組。 Segment spool 產生一個虛擬行來處理最後的群組。

工作表的邏輯讀取計算

• 根據我們的理解，工作表是一個堆（或索引假脫機）如果計劃中另有規定）。在提供的範例中，與預期相反，僅需要 11 次邏輯讀取。對於這種差異的解釋如下：
• 向工作表中的行插入每次都會產生一次邏輯讀取，從而導致 3 次邏輯讀取。
• 計算平均值涉及一次邏輯讀取，總共進行 4 次讀取。
• 傳回具有平均列的行涉及四個邏輯

截斷工作表不會產生邏輯讀取。

這使邏輯讀取總數達到4 x 3 = 12，省略了觸發邏輯讀取的第四行的插入只在原作中

結論

理解這個公式的關鍵在於工作表和常規假脫機表的邏輯讀取計數之間的差異。對於工作表，讀取的每一行都被計算為一次邏輯讀取，而對於假脫機表，每個雜湊頁都被計數。

公式與觀察到的執行情況一致：兩個輔助假脫機被讀取兩次（2 COUNT ())，而主線軸發出(COUNT(DISTINCT CustomerID) 1) 行，如附加資訊中所提及的部落格條目所述。額外的一個是由於發出額外的行來指示最後一組的結束。

以上是為什麼視窗聚合函數會導致 SQL Server 中如此高的邏輯讀取？的詳細內容。更多資訊請關注PHP中文網其他相關文章！