带/不带ADDCOLUMNS的SUMMARIZE功能适用场景及两种DAX写法差异

一、适用场景区分 #

1. 纯SUMMARIZE的适用场景 #

• 仅需基于分组列做简单聚合计算，无需额外上下文调整时使用。比如直接对分组行执行SUM、COUNT这类基础聚合，不需要嵌套复杂CALCULATE逻辑的场景。
• 追求代码结构紧凑，想在同一个函数里一次性完成分组和所有聚合列定义的简单汇总场景。

2. ADDCOLUMNS + SUMMARIZE的适用场景 #

• 需要先确定分组维度（用SUMMARIZE生成基础分组表），再为每个分组添加多个需独立上下文计算的列时。比如给同一分组同时计算销售额总和、客单价、同比增长率，每个列的CALCULATE逻辑不同，分开写更清晰。
• 聚合逻辑依赖分组后上下文，且需要明确控制筛选上下文时。比如先得到年份+颜色的分组，再计算“该分组占全年总销量的比例”，这种需先固定分组再做二次计算的场景。
• 对代码可读性要求高的场景：把分组逻辑和列计算逻辑分离，后期维护时更容易修改某一部分的计算规则，不用在SUMMARIZE里混杂查找分组列和聚合列。

二、两种DAX写法的差异对比 #

选项1代码： #

EVALUATE
ADDCOLUMNS (
    SUMMARIZE (
        Sales,
        'Date'[Year],
        Product[Color]
    ),
    "Total Quantity", CALCULATE ( SUM ( Sales[Quantity] ) )
)

选项2代码： #

EVALUATE
SUMMARIZE (
    Sales,
    'Date'[Year],
    Product[Color],
    "Total Quantity", CALCULATE ( SUM ( Sales[Quantity] ) )
)

核心差异： #

1. 执行逻辑顺序

   • 选项1：先通过SUMMARIZE生成仅包含Date[Year]和Product[Color]的分组表（无聚合列），再通过ADDCOLUMNS为每一行分组添加“Total Quantity”列，此步骤的CALCULATE基于当前分组的上下文筛选Sales表计算总和。
   • 选项2：直接在SUMMARIZE内部完成分组和聚合列计算，SUMMARIZE会同时处理分组列和聚合表达式，自动为每个分组计算聚合值。

2. 上下文稳定性

   • 选项1的CALCULATE上下文更明确：先有固定的分组表，ADDCOLUMNS中的计算完全基于分组表的行上下文转换的筛选上下文，不易出现意外的筛选泄漏。
   • 选项2的SUMMARIZE处理聚合列时，内部筛选上下文可能受Sales表本身的关系影响，若Sales表和其他表有复杂关联，偶尔会出现不符合预期的聚合结果（比如多对多关系下的重复计算），但简单模型中差异不大。

3. 扩展性

   • 选项1扩展性更强：要添加新的聚合列，直接在ADDCOLUMNS后追加即可，比如加"Total Sales", CALCULATE(SUM(Sales[Amount]))，分组逻辑无需改动。
   • 选项2添加新列需在SUMMARIZE参数中继续补充，当聚合列较多时，代码会变得拥挤，分组列和聚合列混杂，可读性下降。

4. 性能表现

   • 简单模型、数据量小时，两者性能几乎无差异。
   • 数据量大或模型关系复杂时，选项1性能更稳定：SUMMARIZE先生成精简的分组表，后续ADDCOLUMNS的计算基于小表做上下文筛选；而选项2的SUMMARIZE可能需同时处理分组和聚合的全表扫描，某些情况下效率略低。

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