DAX 查詢中的迭代器和上下文轉換

本教程將討論上下文轉換和嵌套迭代器。您將了解這些實體的重要性以及它們如何成為優化的良好來源。

如果您還記得，上下文轉換發生在行上下文更改為等效的篩選器上下文時。當迭代器中發生上下文轉換時，您需要了解發生了什麼，因為它通常會產生緩慢的結果。

目錄

• 嵌套迭代器與 CALCULATE
• 結論

嵌套迭代器與 CALCULATE

如果在迭代期間調用上下文轉換，則會創建具體化表。這意味著上下文轉換是通過 DAX 中的公式調用的。該表是發送到公式引擎的未壓縮數據。

為了演示，第一個度量是針對大銷售，如果當前價格大於或等於 500，則獲取當前價格。

下一個度量是使用嵌套迭代器的 Big Sales 的平均值。

最後一個度量在沒有嵌套迭代器和 CallBackDataID 的情況下獲取 Big Sales 的平均值。

使用嵌套迭代器運行測量。確保在運行前清除緩存，然後打開 Server Timings 和 Query Plan。

您可以看到它生成了 3 次掃描、2 個 CallBackDataID 和 15,003 行。這是一個值得關注的原因，因為輸出只有 101 行。發生這種情況是因為度量有兩個迭代器或 X 函數。

這是已運行的度量的完全擴展形式：

它使用迭代 Fact Sales 表。然後它使用再次使用CallBackDataID重申。此度量的縮短格式具有一個隱含的函數，該函數調用上下文轉換並具體化該表。這就是它提取 15,003 行的原因，即使只有 101 行用於輸出。

運行沒有嵌套迭代器的其他度量。它仍在使用AVERAGEX迭代 Fact Sales 表，但當前價格在函數之外。它過濾掉當前價格大於或等於500的產品，然後計算平均值。

您可以看到它只有 2 次掃描，104 行，並且沒有 CallBackDataID。因此，如果您使用CALCULATE，則可以擺脫嵌套的迭代器和CallBackDataIDs。

LuckyTemplates 中的 DAX 函數：使用迭代器
如何在 LuckyTemplates
DAX 計算中使用迭代函數 – 過濾器上下文轉換

結論

DAX 執行緩慢的原因有很多。其中之一是由於嵌套迭代器導致不必要的上下文轉換。這些迭代器具體化了比需要更多的行，這會導致您的查詢變慢。

最好的解決方案是將它放在CALCULATE中。這為公式引擎創造了更少的工作並最大化了存儲引擎的能力。