DAX中SUMX结合GROUPBY计算结果异常问题排查

咱们直接拆解问题核心：你的GROUPBY写法和SUMMARIZE写法的差异，根源在于两者的聚合计算时机和上下文处理逻辑完全不同。

1. 先看两个度量值的逻辑差异 #

（1）GROUPBY版本的问题点 #

myMeasure = SUMX(
    GROUPBY(
        myTable,
        myTable[id],
        "v1", COUNTX(CURRENTGROUP(), myTable[value])
    ),
    [v1]
)

你原本的意图是按[id]分组统计行数，再求和得到总行数，但GROUPBY的延迟计算特性坑了你：

• GROUPBY只负责生成按[id]分组的框架，不会立即计算"v1"的聚合值；
• 只有当SUMX迭代每个分组时，才会触发COUNTX(CURRENTGROUP(), myTable[value])的计算，而此时的计算会被当前迭代上下文+外部筛选上下文双重影响，很容易出现意外的分组限制。

（2）SUMMARIZE版本为什么正确 #

myMeasure = SUMX(
    SUMMARIZE(
        myTable,
        myTable[id],
        "v1", COUNT(myTable[value])
    ),
    [v1]
)

SUMMARIZE是立即聚合的逻辑：

• 它会先完成按[id]的分组，同时直接计算每个组的COUNT(myTable[value])，生成一个包含每个id对应行数的中间表；
• 之后SUMX只需要对这个中间表的[v1]列求和，逻辑清晰且不受后续上下文干扰，自然能得到正确的总计。

2. 你的场景里GROUPBY出错的具体原因 #

当矩阵按[date] x [id]展示，且筛选了2019年3月+[id]=20026时：

• 明细行：每个单元格的筛选上下文是「某一天+该id」，GROUPBY生成仅包含当天该id行的分组，COUNTX返回1，这部分是正常的；
• 总计行：DAX的总计行是独立重新计算的（不是明细行的简单求和），此时筛选上下文是「整个3月+该id」。按道理应该返回31，但你得到5，大概率是GROUPBY的延迟计算导致CURRENTGROUP()意外继承了视觉对象的隐性分组（比如[date]被自动按周/旬分组，或者数据中[value]存在未注意到的重复/空白逻辑），使得COUNTX只统计了部分行。

3. GROUPBY版本的修正方案 #

如果你坚持要用GROUPBY，可以改成直接统计分组行数（避免[value]的干扰），确保CURRENTGROUP()的引用逻辑正确：

myMeasure = SUMX(
    GROUPBY(
        myTable,
        myTable[id],
        "v1", COUNTROWS(CURRENTGROUP())
    ),
    [v1]
)

其实更简单的是，你的需求本质就是统计总行数，直接用COUNT(myTable[value])或者COUNTROWS(myTable)即可，完全不需要嵌套SUMX和分组函数。

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