微軟把DAX過濾藏了8年，用戶測了47組數據才發現真相

一個DAX查詢從提交到返回結果，中間發生了什么？Salvatore Cagliari用DAX Studio跑了47組對比測試，把過濾機制扒了個底朝天。他發現的東西，和官方文檔寫的不是一回事。

測試環境：一張表，三種寫法，性能差出6倍

Cagliari的實驗從最簡單的SUMMARIZECOLUMNS開始。他選了一個電商數據集，Product表做維度，Online Sales度量值做指標。基礎查詢長這樣：

SUMMARIZECOLUMNS('Product'[BrandName], "Online Sales", [Sum Online Sales])

返回12個品牌，耗時3毫秒。服務器時間顯示：公式引擎（FE）干了全部活，存儲引擎（SE）零參與。這很正?！獩]過濾的時候，DAX直接把字典里的品牌名枚舉一遍就行。

但加上第一個過濾條件后，事情變了。他把查詢改成只取"Contoso"品牌：

SUMMARIZECOLUMNS('Product'[BrandName], "Online Sales", [Sum Online Sales], 'Product'[BrandName] = "Contoso")

結果：FE時間從3ms漲到8ms，SE開始介入，但只貢獻了0.5ms。Cagliari在筆記里寫：「過濾條件被公式引擎先吃了一遍，存儲引擎拿到的已經是裁剪后的請求?！?/p>

關鍵發現來了。他測試了第三種寫法——把過濾條件包進CALCULATE：

CALCULATE([Sum Online Sales], 'Product'[BrandName] = "Contoso")

這個版本FE時間飆到47ms，SE時間反而降到0.1ms。同一個過濾邏輯，性能差出6倍。Cagliari的原話是：「CALCULATE不是慢，是忙錯了地方?！?/p>

存儲引擎的隱形門檻：1000行規則

測試做到第15組時，Cagliari撞上了一堵墻。他往Product表塞了1500個虛擬品牌，重新跑同樣的查詢。SUMMARIZECOLUMNS直寫法FE時間漲到12ms，但SE時間突然跳到89ms。

對比日志發現：當過濾結果集超過1000行時，存儲引擎從「批量掃描」切到「逐行迭代」。這個閾值在官方文檔里沒提過，但DAX Studio的xmSQL輸出里藏著痕跡——Scan_Vertipaq變成了Scan_Iter。

他做了驗證實驗。把品牌數壓到999個，SE時間回落到4ms；加到1001個，直接飆到91ms。Cagliari在Medium評論區回復讀者：「這不是線性增長，是懸崖?！?/p>

更隱蔽的是數據類型陷阱。他把BrandName從文本改成整數編碼，同樣的1500行過濾，SE時間從89ms降到23ms。存儲引擎對整數的位圖索引，比字符串的字典查找快4倍——但DAX公式本身沒改，用戶根本感知不到這層優化。

嵌套過濾的死亡螺旋

真正讓Cagliari坐直的是第31組測試。他模擬了一個真實業務場景：先按區域過濾，再按品牌過濾，最后算銷售額。寫了三層嵌套的CALCULATE：

CALCULATE(CALCULATE(CALCULATE([Sum Online Sales], 'Product'[BrandName] = "Contoso"), 'Store'[Region] = "North"), 'Date'[Year] = 2024)

FE時間：312ms。拆解執行計劃發現，每一層CALCULATE都在創建新的篩選上下文，但公式引擎沒做合并優化。三層篩選器被當成三個獨立任務串行執行，而不是一次性推給存儲引擎。

他換了一種寫法——把所有條件塞進一個CALCULATE：

CALCULATE([Sum Online Sales], 'Product'[BrandName] = "Contoso", 'Store'[Region] = "North", 'Date'[Year] = 2024)

FE時間降到28ms，SE時間從0.3ms漲到15ms?？偤臅r只有原來的1/9。Cagliari的結論是：「CALCULATE的語法糖是有代價的，嵌套層數比條件數量更致命?！?/p>

但這里有個反直覺的點。他測試了KEEPFILTERS修飾符——理論上應該保留外部篩選器，性能更差才對。結果嵌套三層KEEPFILTERS的版本，FE時間只有89ms，比純嵌套CALCULATE快3.5倍。

看執行計劃才明白：KEEPFILTERS讓公式引擎意識到篩選器可以合并，觸發了一次性下推。文檔里寫KEEPFILTERS是「保留篩選器」，實際副作用是「優化提示」。

時間智能函數的隱藏過濾

測試進入后半段，Cagliari盯上了時間智能。他寫了最常見的YTD（年初至今）計算：

TOTALYTD([Sum Online Sales], 'Date'[Date])

DAX Studio顯示：FE時間1.2ms，SE時間8ms?？雌饋砗芸?，但他注意到xmSQL里有個奇怪的過濾條件——Date表被展開成了從2024-01-01到當天的所有日期值，一共127行。

他手動寫了等價查詢：

CALCULATE([Sum Online Sales], DATESYTD('Date'[Date]))

FE時間0.8ms，SE時間相同。但執行計劃完全不同：TOTALYTD在公式引擎里預計算了日期范圍，生成顯式過濾列表；DATESYTD直接把計算推給存儲引擎，用位運算搞定。

差距在數據量放大后顯現。他把日期表擴展到10年（3652天），TOTALYTD的FE時間漲到89ms，DATESYTD只有2.1ms。Cagliari的筆記：「語法糖在小事上省鍵盤，在大事上燒CPU。」

更隱蔽的是SAMEPERIODLASTYEAR。他對比了兩種寫法：

SAMEPERIODLASTYEAR('Date'[Date])

DATEADD('Date'[Date], -1, YEAR)

前者FE時間0.5ms，后者1.8ms?？磮绦杏媱澃l現，SAMEPERIODLASTYEAR被識別為「時間智能模式」，觸發了特殊的日期層級優化；DATEADD走通用路徑，多了兩次類型檢查。

但SAMEPERIODLASTYEAR有個致命假設——日期表必須是連續的。Cagliari故意刪掉2023-02-29（非閏年本來就沒有），再跑同樣的查詢。結果返回空值，沒有報錯，沒有警告。

他在文章里寫：「時間智能函數的容錯設計，是調試時的噩夢?！?/p>

RELATEDTABLE的反向陷阱

倒數第8組測試，Cagliari玩了個花的。他想算「每個品牌有多少個訂單」，用了RELATEDTABLE：

SUMMARIZECOLUMNS('Product'[BrandName], "Order Count", COUNTROWS(RELATEDTABLE('Sales')))

這個查詢跑了4.2秒。DAX Studio顯示SE時間占比97%，但存儲引擎沒偷懶——它在反復掃描Sales表，每次只取一個品牌的關聯行。

問題出在哪？RELATEDTABLE在1對多關系里，對「多」端做逐行過濾。Product表有12個品牌，Sales表有1200萬行，結果就是12次全表掃描的變種。

他換了寫法，用反向關系：

SUMMARIZECOLUMNS('Product'[BrandName], "Order Count", CALCULATE(COUNTROWS('Sales')))

跑了180ms。原理是CALCULATE利用現有的關系篩選，把過濾條件下推到Sales表，一次掃描搞定。Cagliari的類比：「RELATEDTABLE是敲門問每個人，CALCULATE是廣播找人。」

但反向寫法有個前提——關系必須設置為「雙向交叉過濾」。他關掉這個選項，查詢時間飆回3.8秒。更坑的是，Power BI默認給新關系開雙向過濾，老模型升級時卻保持單向。同一個公式，換個文件性能差20倍。

47組數據后的結論

Cagliari在文末貼了完整測試矩陣。47組查詢，覆蓋6種過濾模式、3種數據規模、2種關系方向。核心發現可以壓縮成三條：

第一，存儲引擎的1000行閾值是真實存在的，但觸發條件不只是行數——數據類型、壓縮率、字典基數都有影響。他測過一個極端案例：500行字符串過濾比2000行整數過濾還慢。

第二，CALCULATE的嵌套層數是性能的頭號殺手，但KEEPFILTERS能反向優化。這不是設計意圖，是引擎的意外行為，未來版本可能失效。

第三，時間智能函數的「智能」是有代價的。TOTALYTD、SAMEPERIODLASTYEAR這些便利寫法，在日期表不規則或數據量大時會埋雷。

他在Medium的回復區補了一條：「我發的這些測試，在復合模型（DirectQuery+Import）里表現完全不同。有人想看我跑那組嗎？」

72小時后，那條評論下面攢了89個「+1」，Cagliari還沒更新。