Power BI 深度解析：重塑 SUM 与 SUMX 的 2026 开发者思维

• table: 要遍历的表。这可以是物理表，也可以是返回表的函数（如 FILTER, ALL, VALUES 等）的结果。
• expression: 对每一行计算的表达式。这个表达式的结果必须是一个数字。

#### 核心工作原理

SUMX 的工作流程可以分为两个步骤：

• 遍历： SUMX 首先进入迭代模式，它接收你指定的


#### 实战演练：计算折扣后的销售总额

让我们回到之前的销售数据集。假设我们的数据表中没有直接的“销售总额”列，只有 INLINECODEd79a0904（单价）和 INLINECODE9cfba118（数量），并且我们需要根据每个产品的 Discount（折扣率）来计算最终的实际销售额。SUM 无法直接完成这个任务，因为它是基于单列的。这时候，SUMX 就派上用场了。

场景描述：

我们需要计算：实际销售额 = SUM( 单价 * 数量 * (1 - 折扣率) )

示例度量值 1：基础行级计算

// 这是一个 SUMX 的经典用法
// 我们逐行计算“单价 * 数量”，然后将所有行的结果加起来
Total Sales Extended = 
SUMX(
    Orders, 
    Orders[Unit Price] * Orders[Quantity]
)

代码解析：

• 第一参数 (INLINECODE4a78f094)：告诉 SUMX 要遍历 INLINECODE21e2829e 表的每一行。
• 第二参数 (Orders[Unit Price] * Orders[Quantity])：对于特定的一行，DAX 引擎会取出这一行的单价，乘以这一行的数量，得到一个临时的数字。
• 最终动作：SUMX 会把这些临时的数字全部累加起来。

企业级实战：处理计算列与动态聚合的博弈

在我们最近的一个大型企业财务报表项目中，我们遇到了一个典型的性能难题：是使用计算列加上 SUM，还是直接使用 SUMX？这在 2026 年依然是一个热门话题，尤其是在处理 VertiPaq 存储引擎的内存限制时。选择错误的方案会导致模型加载缓慢或查询超时。

#### 场景：加权平均毛利率的计算

假设我们需要计算每个产品类别的加权平均毛利率。这不仅涉及到总和，还涉及到除法，这就必须在行级别进行计算。

错误的 SUM 尝试：

如果你试图写 SUM(Profit) / SUM(Sales)，你会得到整体的总利润率，而不是按单笔交易加权后的平均值。

正确的 SUMX 实现：

// 企业级：加权平均毛利率计算
// 我们首先在行级别计算每笔交易的毛利率，然后基于销售额进行加权
Weighted Avg GM = 
VAR TotalSales = SUM(Orders[Sales Amount])
VAR WeightedProfit = 
    SUMX(
        Orders,
        // 逐行计算：该行利润 * (该行销售额 / 总销售额)
        // 这里我们在迭代中引用了外部变量 TotalSales
        VAR CurrentRowSales = Orders[Sales Amount]
        VAR CurrentRowProfit = Orders[Profit Amount]
        RETURN
            IF(
                TotalSales  0,
                CurrentRowProfit * (DIVIDE(CurrentRowSales, TotalSales)),
                0
            )
    )
RETURN
    WeightedProfit

代码深度解析：

在这段代码中，我们展示了现代 DAX 开发的一个重要理念：变量的使用。通过 INLINECODE2789c495 关键字，我们将 INLINECODE401b7a36 提取出来。这不仅提高了代码的可读性，更重要的是优化了性能。SUMX 在遍历时，不需要重复计算总销售额，而是直接调用内存中的变量。在处理数百万行数据时，这种微小的优化能带来显著的性能提升。这就是 2026 年我们所倡导的“显式编程”风格——清晰地定义每一步的逻辑。

2026 技术前沿：Vibe Coding 与 AI 辅助开发

作为 2026 年的开发者，我们必须学会利用 AI 工具。这里有一个我们在内部推广的“Vibe Coding”技巧：如何让 AI 帮助你编写复杂的 SUMX 逻辑。在过去，我们需要在脑海中构建复杂的嵌套循环，现在我们可以利用 Agentic AI（代理式 AI）来辅助这一过程。

#### AI 辅助工作流

当你面对一个复杂的逻辑，例如“计算每个客户在过去 30 天内购买 A 类产品且金额大于 200 的次数”，直接写 DAX 可能会很吃力。不要只对 Cursor 或 GitHub Copilot 说：“写一个 DAX 公式”。这是一种低效的交互方式。

你应该这样问，使用“意图-结构-结果”的 Prompt 策略：

> “我有一个 Sales 表和一个 Customer 表。我想创建一个度量值。请使用 SUMX 迭代 Sales 表，筛选条件是日期属于过去 30 天（使用 DATESINPERIOD），且产品类别为 ‘A‘。在 SUMX 的表达式内部，如果销售额 > 200，则计数为 1，否则为 0。请确保处理好行上下文过渡，并使用变量来优化代码结构。”

AI 生成的代码框架：

// AI Generated High Value Txn Count
// 体现了现代 AI 辅助编码的最佳实践：清晰的变量命名和逻辑分层
High Value Txn Count = 
VAR Last30Days = 
    DATESINPERIOD(
        ‘Date‘[Date], 
        MAX(‘Date‘[Date]), 
        -30, 
        DAY
    )
VAR FilteredTable = 
    FILTER(
        Sales,
        Sales[Category] = "A" && 
        Sales[Date] IN Last30Days
    )
RETURN
    SUMX(
        FilteredTable,
        IF(Sales[Amount] > 200, 1, 0)
    )

通过这种方式，我们不仅让 AI 编写了代码，更重要的是，我们通过 Prompt 强制 AI 遵循了最佳实践：先定义表变量，再进行迭代。这是一种非常符合现代工程理念的协作方式。AI 帮我们处理了繁琐的语法，而我们人类专家则专注于业务逻辑的准确性。

性能优化的 2026 版指南与陷阱规避

随着硬件性能的提升，虽然我们拥有了更强的算力，但数据量也在呈指数级增长。在 2026 年，一个优秀的数据建模师必须像关注业务逻辑一样关注性能。

#### 1. 存储空间 vs 计算速度

• SUM (配合计算列): 如果你选择在 Power Query 中创建一个计算列 INLINECODEf287921d，然后使用 INLINECODEbeecc420，你是把计算时间花在了数据刷新时，增加了模型文件的大小，但查询速度极快。
• SUMX (配合度量值): 如果你使用 SUMX(Table, [Price] * [Qty])，你并没有增加模型的大小，计算是在用户查看报表时实时进行的。

我们的建议： 在 2026 年，随着内存成本的降低，对于相对静态的、不依赖筛选上下文的简单乘法，我们倾向于使用计算列以获得极致的查询性能。但对于动态逻辑（例如折扣率受切片器影响），必须使用 SUMX。

#### 2. 避免上下文转换的陷阱

很多人在使用 SUMX 时会无意中触发昂贵的“上下文转换”。这通常发生在 SUMX 的表参数是一个需要从行上下文转换为筛选上下文的表（如 VALUES 或 DISTINCT），而内部又引用了度量值时。

低效写法（可能导致性能瓶颈）：

// 这里的 SUMX 内部引用了一个度量值，可能触发昂贵的上下文转换
SUMX(
    VALUES(Product[Category]),
    [Total Sales Measure]
)

优化后的写法：

如果可能，尽量在 SUMX 内部直接引用列，或者确保度量值经过充分优化。在现代开发中，我们甚至可以利用 Performance Analyzer 来检测这种上下文转换带来的延迟。

最佳实践总结与未来展望

随着 Power BI 引擎的不断演进，虽然 DirectQuery 模式下的性能有所提升，但对于 SUM 和 SUMX 的理解依然是核心。以下是我们的最终建议：

• 优先使用 SUM：如果业务逻辑允许，尽量在数据库端或 Power Query 中完成计算，生成物理列，然后使用 SUM 进行聚合。这通常是最快的。
• 善用 SUMX 处理动态逻辑：对于无法预先计算的、基于动态筛选或复杂条件的业务逻辑，SUMX 是不可或缺的工具。
• 拥抱变量 (VAR)：在 2026 年，没有 VAR 的 DAX 代码是不专业的。VAR 极大地提升了代码的可维护性，并帮助引擎优化查询计划。
• 利用 AI：不要害怕写错，利用 AI 工具快速生成原型，然后人工审查其逻辑是否正确处理了上下文。让 AI 成为你学习 DAX 的加速器。

在接下来的学习之路上，我们建议你尝试修改现有的度量值，试着将一些使用 SUM 计算的简单度量值改写为 SUMX，观察结果是否一致；然后，试着构建一个需要 SUMX 才能计算的复杂场景，例如“只计算周末的销售额总和”。通过不断的实验，你将会对这两个函数有更深刻的体会。祝你探索愉快！