DAX性能问题：为何使用变量的SUMX加筛选后运行缓慢？

• 核心度量值的三个基础版本定义：
  • 版本A：CALCULATE(SUM(...))，无论是否叠加FILTER筛选，所有计算逻辑都可由存储引擎完成，运行速度极快
  • 版本B：SUMX(..., IF some_column = 常量, other_column)，计算逻辑基本由存储引擎承载，运行速度与版本A接近
  • 版本C：SUMX(..., IF some_column = 变量, other_column)，未叠加FILTER筛选时可由存储引擎完成计算；一旦叠加FILTER筛选，就会触发查询引擎参与计算，运行速度大幅下降
• 已知前提：
  • 版本C中引用的变量在实际查询上下文中计算结果始终固定为"Monthly"，与版本B使用的常量值完全一致，但二者性能表现存在显著差异
  • 排查过程中已同步附带两类参考材料：版本C无筛选时存储引擎承载全量计算、添加筛选后查询引擎介入的执行截图；相关表关系示意图
• 核心待解答问题：
  • 版本B与版本C性能差异巨大的底层原因
  • 保留变量引用逻辑的前提下，实现与版本B相当的存储引擎计算性能的方法
  • 通过筛选配置调整，避免不必要的查询引擎介入的可行性

• 存储引擎的计算下推判定规则：只有当表达式内的所有判断值都是预编译阶段可确定的静态常量、不依赖动态上下文解析结果时，引擎才会把行级判断、聚合计算全量下推到VertiPaq存储引擎层执行
• 版本B的执行路径：IF判断中的右值是硬编码常量，DAX引擎在预编译阶段即可识别完整判断逻辑，所有计算可直接由列存结构的存储引擎完成，不需要将明细数据拉取到查询引擎层二次计算
• 版本C的执行路径触发条件：IF判断中的右值是变量，哪怕变量最终取值固定，引擎在预编译阶段也无法直接确认变量是否依赖动态上下文计算结果——特别是叠加FILTER筛选后，筛选上下文的变化会让引擎无法提前判定变量的静态可解析性，因此必须将SUMX遍历的全量明细数据拉取到查询引擎层，逐行完成判断、聚合运算，这部分计算的内存开销、执行延迟远高于存储引擎的列存计算效率

优化核心逻辑：在预编译阶段向引擎传递“变量取值为静态可确定值”的信号，让判断逻辑可顺利下推到存储引擎

• 方案1：将变量取值的判断逻辑前置为CALCULATE的筛选参数，替代SUMX内部的逐行IF判断

  优化后的版本C =
  VAR CurrentTargetValue = [你的原有变量逻辑]
  RETURN
  CALCULATE (
      SUM ( other_column ),
      FILTER ( 目标表, some_column = CurrentTargetValue )
  )
  

• 方案2：对固定取值的判断条件使用KEEPFILTERS修饰，降低引擎的动态解析判定概率

  优化后的版本C =
  VAR CurrentTargetValue = [你的原有变量逻辑]
  RETURN
  CALCULATE (
      SUMX (
          目标表,
          other_column
      ),
      KEEPFILTERS ( some_column = CurrentTargetValue )
  )
  

• 筛选适配调整建议：
  • 叠加FILTER筛选时，不要将筛选条件与SUMX迭代逻辑直接嵌套，将所有筛选条件统一放置在CALCULATE的参数列表中，减少查询引擎对迭代上下文的动态判定
  • 对取值固定的筛选条件，优先使用KEEPFILTERS修饰，避免引擎因上下文转换的不确定性，将计算逻辑拉到查询引擎层执行

内容的提问来源于stack exchange，提问作者Eric Mamet