性能優化，在 DAX 中是很重要的問題，對 DAX 的性能優化大致可以歸結為針對 SE（存儲引擎） 或 FE（公式引擎） 的性能優化。
如果可以確保 SE 和 FE 都在最好的狀態下工作，那麼 DAX 將得到充分的發揮。而往往分析師會更加關注業務邏輯的表達，但我們開始研究寫出更快的 DAX 時，我們將成為會修車的分析師了。我們會通過一系列文章來幫助大家在各個角度來體會 DAX 的性能優化技術。
今天我們來看一個案例。
看一個案例，我們想知道大訂單的個數，如下：
OrderPurchaseNumber =
CALCULATE(
DISTINCTCOUNT( 'Order'[OrderID] ) ,
FILTER(
'Order' ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
)
大訂單的定義為包含單價大於1000且利潤大於0的訂單。
這個定義沒有問題，放在 PowerBI 中的計算也是正確的，但不久就會發現它的性能問題，於是，通過 DAX Studio 來檢查可以看到：
我暈，居然驚現了 779 個查詢。
該查詢的意義是計算每天的大訂單個數。但這種方法顯然是不行的。雖然在度量值的定義上非常自然。
我們再來看看從 PowerBI 中拖拽的情況，如下：
如果研究該圖表背後的 DAX 查詢，其結果和上述內容是一致的。
那麼問題來了，我們建立了一個基礎度量值叫：OrderPurchaseNumber，其邏輯也很清楚，但卻有如此之差的性能，怎麼辦呢？
原因分析這裡的問題在於發起了對 SE 的多次查詢，不難察覺：
FILTER(
'Order' ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
這裡使用了 Order 表作為 FILTER 的參數，而且位於基礎度量值的位置，導致在迭代日期時，每次都會做單獨計算，導致對 SE 的過度重複訪問。
改進措施有一種做法是，可以將度量值改為：
OrderPurchaseNumber =
CALCULATE(
DISTINCTCOUNT( 'Order'[OrderID] ) ,
FILTER(
ALL( 'Order' ) ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
)
注意，這裡用了 ALL( 『Order』 ) 而非 『Order』 ，這顯然是不對的，因為它改變了語義。
那麼進而想到另一種方式為：
OrderPurchaseNumber =
CALCULATE(
DISTINCTCOUNT( 'Order'[OrderID] ) ,
FILTER(
ALL( 'Order'[LinePrice] , 'Order'[LineProfit] ) ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
)
這樣的方式僅僅使用需要用到的兩列，而非整個表，來看下效果：
性能得到了非常恐怖的提升。
但細心的夥伴會發現，這種寫法的努力方向是對的，但這種寫法還是錯誤的，因為：
FILTER(
ALL( 'Order'[LinePrice] , 'Order'[LineProfit] ) ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
作為篩選器參數，會覆蓋外部的篩選，這也是不正確的邏輯，所以，需要進一步優化為：
OrderPurchaseNumber =
CALCULATE( DISTINCTCOUNT( 'Order'[OrderID] ) ,
KEEPFILTERS(
FILTER(
ALL( 'Order'[linePrice] , 'Order'[LineProfit] ) ,
'Order'[LinePrice] > 1000 && 'Order'[LineProfit] > 0
)
)
)
性能結果為：
完美。
總結當需要在基礎度量值中使用篩選條件時，必須注意：
僅僅使用所必須的列，提升性能
使用 KEEPFILTERS 包裹，確保邏輯正確
這樣，基礎度量值就可以攜帶複雜的篩選器參數而不影響性能了。
精彩直播及視頻可以到B站二次元
本文內容【源文件+視頻講解】從屬於：年度訂閱會員，已發布請享用。
讓數據真正成為你的力量
加私信暗號：data2020