DAX CALCULATETABLE 與 FILTER 函數

CALCULATETABLE和強大工具，但它們有一些重要的區別，需要理解。

在此博客中，我們將回顧DAX studio 中的CALCULATETABLE函數及其查詢計劃，並了解它與FILTER函數的區別。到最後，您將更好地了解如何為您的數據分析需求選擇正確的函數。

為了演示，我們將使用下面的 DAX 代碼。

運行此代碼時，您將獲得一個顯示品牌和顏色的表格。

在Query Plans選項卡中，您將獲得與Formula Engine中的CrossApply運算符對應的代碼。

同時，您可以看到代碼僅在Server Timings選項卡中檢索產品顏色和品牌。

目錄

• CALCULATETABLE 的 DAX Studio 服務器計時結果
• DAX Studio 中的 CALCULATETABLE 查詢計劃
• 類似 DAX 函數的上下文轉換
  • 服務器時間
  • 查詢計劃
• 結論

CALCULATETABLE 的 DAX Studio 服務器計時結果

例如，讓我們過濾產品顏色以僅顯示紅色和/或黑色。

您可以使用 FILTER 函數來執行此操作。當您運行它時，Server Timings 將顯示 FILTER 參數未應用於xmSQL 代碼。

但是如果您使用 CALCULATETABLE 函數，Server Timings 選項卡中的查詢將顯示結果已按產品顏色過濾。

DAX Studio 中的 CALCULATETABLE 查詢計劃

讓我們看看每個函數的查詢計劃。

CALCULATETABLE 位於邏輯查詢計劃的第一行，因為它是代碼中的頂級函數，因此不依賴於任何要求。

當您閱讀 CALCULATETABLE 函數的查詢計劃時，您不會從第一個參數開始。您首先需要了解所使用的過濾器上下文。那麼讓我們轉到第 5 行。

您可以看到，由於應用了過濾器，VertiPaq運算符需要產品顏色列。然後它掃描此列並使用Not IsEmpty 篩選器組合來檢查每一行的產品顏色。

過濾器上下文準備好後，將執行

事後看來，如果您使用 FILTER 函數，您將看到一個不同的查詢計劃，因此 CROSSJOIN 參數在識別過濾器上下文之前執行。

這種方法的缺點是它不會將篩選條件推送到存儲引擎。您將無法在 xmSQL 中使用WHERE子句，這會給公式引擎帶來沉重的負擔。

當您處理多個表時，CROSSJOIN 函數的過濾器組合將非常龐大。這會降低 DAX 代碼的性能。因此，在大多數情況下，建議使用 CALCULATETABLE 函數。

因此，您可以在 XMSQL 代碼的 WHERE 類中註入過濾條件，而不是在公式引擎中執行所有計算。

類似 DAX 函數的上下文轉換

服務器時間

此概念也適用於 CALCULATE 函數。我們以下面的 DAX 代碼為例。

一個度量自動有一個 CALCULATE 函數圍繞著它。

運行此代碼時，您將獲得一個表格，顯示每種顏色的總銷售額。

在 Server Timings 選項卡中，您可以看到代碼正在執行兩個查詢。第一個查詢是計算 Sales 表中關於 Products 表的銷售額總和。

另一方面，第二個查詢再次從 Products 表中檢索產品顏色。它對應於DAX 代碼中的

公式引擎並排放置兩個查詢的數據緩存。它首先從第二個數據緩存中檢索值，然後在第一個數據緩存中執行查找。

查詢計劃

在查詢計劃選項卡中，由於參數，邏輯查詢計劃掃描產品顏色。

然後，VertiPaq 根據產品顏色匯總總銷售額。它執行將產品顏色值轉換為等效過濾器上下文的上下文轉換。

上下文轉換創建的過濾器被轉換為查詢計劃中的DependOnCols屬性。在 VertiPaq 掃描計算總銷售額所需的列後，它將銷售數量乘以淨價。

然後以貨幣數據類型的形式返回總銷售額作為結果。最後，ADDCOLUMNS 返回一個包含兩列的表，其中包含顏色和總銷售額。

結論

查詢計劃會對查詢的性能產生重大影響，因為不同的查詢計劃可能具有不同的效率級別。

在 DAX 查詢中使用 CALCULATETABLE 和 FILTER 函數時，查詢計劃可能會因具體場景和多種因素而有所不同，例如使用的具體公式表達式和查詢引擎的能力。

一般來說，測試和比較不同查詢計劃的性能以確定給定場景的最有效方法是個好主意。

一切順利，