微软Power BI用户花3年搞懂：80%业务问题只需5个公式

CALCULATE、SUMX、DATESINPERIOD、FILTER、DIVIDE——这五个函数的名字，在Power BI社区被搜索了超过1200万次。

但诡异的是，90%的初学者仍在收藏夹里囤着200多个DAX函数的速查表，仿佛备考一样背诵。一位在零售行业做了四年数据分析的从业者告诉我：「我前三年都在假装自己懂DAX，直到发现每天用的其实就那五个。」

这不是技能焦虑，是信息过载制造的幻觉。

CALCULATE：业务问题的「如果」按钮

想象你手里有一个计算器，但每次按数字键之前，必须先告诉它「假装现在是另一种情况」。这就是CALCULATE干的事——它改变计算的上下文，而不碰原始数据。

原文作者给出的例子很直白：你想知道高端产品线的销售额，但不想动原始表格。写成公式就是CALCULATE(SUM(Sales[Amount]), Products[Category] = "High-End")。第一个参数是你要算什么，后面的条件是「假装只看高端类别」。

这个函数的真正价值在于提问方式。业务场景里全是「如果」——如果只看华东区？如果剔除退货？如果对比去年同期？没有CALCULATE，每个问题都要新建一张表；有了它，一个度量值（Measure）就能变出十几种视角。

作者把它称为「the king」，不是夸张。在真实的Power BI项目里，CALCULATE的嵌套深度直接决定了分析模型的灵活度。我见过最复杂的零售分析模型，核心逻辑是四层CALCULATE套娃：先锁时间、再锁区域、再锁产品层级、最后动态对比。

SUMX：为什么简单求和会骗人

很多初学者栽在第一个坑：直接用SUM算总收入。如果数据表里有「单价」和「数量」两列，SUM(Price) * SUM(Quantity)会给出荒谬的结果——它先加总所有单价，再乘以所有数量，完全丧失行级关系。

SUMX的X代表「逐行计算」。公式SUMX(Sales, Sales[Price] * Sales[Quantity])的意思是：遍历Sales表的每一行，把单价和数量乘好，最后再把所有行的结果加起来。

这个区别在业务里是要命的。假设你卖两种产品：A单价100元卖10件，B单价10元卖100件。错误算法会算出(100+10)*(10+100)=12100，正确结果是100*10+10*100=2000。差了一个数量级。

原文作者提到SUMX是「row-by-row calculator」，这个类比精准。X函数家族还有AVERAGEX、MINX、MAXX，逻辑相同：先迭代，再聚合。处理加权平均、分段计价、动态折扣这些场景，非X函数不可。

DATESINPERIOD：时间维度的自动化

手动改日期筛选器是分析师的重复劳动噩梦。每个月初打开报表，把「最近30天」改成「最近30天」——听起来荒谬，但无数人这么干了几年。

DATESINPERIOD的公式结构有点绕：DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -3, MONTH)。拆解一下：以日期表的最大日期为锚点，往回推3个月。负号代表过去，MONTH代表单位，换成DAY或YEAR就是另外两种粒度。

这个函数的隐藏价值是「相对时间」思维。业务问题很少问「2024年3月到5月」，而是问「最近90天」「滚动12个月」「同比周期」。DATESINPERIOD把绝对日期转成相对逻辑，报表永远自动对准最新数据。

作者强调它「automates your reports」，这背后是BI的核心卖点：一次搭建，持续生效。没有这个时间函数，Power BI就退化成Excel的高级版。

FILTER和DIVIDE：防御性编程思维

这两个函数放在一起看，会发现作者的一个隐性偏好：处理脏数据和边界情况。

FILTER解决的是「动态条件」问题。前面的CALCULATE能筛固定值，比如Category="High-End"，但如果条件是「销售额超过1000的客户」呢？这个阈值是算出来的，不是原始列里写死的。

原文的例子嵌套了三层：外层CALCULATE算客户数，中间FILTER筛客户，内层再CALCULATE算每个客户的销售额。这种「用计算结果当筛选条件」的模式，在客户分层、RFM分析、异常检测里高频出现。

DIVIDE则是更基础的防御。做除法时，分母为零是常态——新店还没开张、新产品还没动销、某区域暂时断货。原生除法符「/」会返回Infinity或NaN，报表上炸出一堆错误值。

DIVIDE([Total Profit], [Total Revenue], 0)的第三个参数是「备用值」。分母为零时返回0，报表干净，下游计算不会连锁崩溃。这个细节区分了「能跑」和「能用的」模型。

作者把这叫「safe way」，本质是产品经理的兜底思维：用户不会按说明书出招，系统必须自己擦屁股。

一个真实场景的组合拳

原文最后抛了一个零售经理的日常问题：「哪些产品利润率超20%，且最近90天销量过500件？」

拆解这个需求，五个函数全部登场：DATESINPERIOD锁定最近90天，SUMX算销量（如果涉及多字段），CALCULATE切换计算上下文，FILTER筛出利润率和销量的双重条件，DIVIDE保证利润率计算不报错。

这不是炫技，是业务语言的直接翻译。好的DAX模型读起来像白话：「算一下，在那些利润率够高、卖得够多的产品里，情况是怎样的？」

作者说「You don't need to be a programmer」，这句话的潜台词更值得玩味。Power BI的竞争对手是Python、R、SQL，但微软的赢法从来不是功能最全，而是把技术概念包装成业务人员能直觉理解的形状。五个函数覆盖80%场景，剩下的20%留给专业开发者——这个分工本身，就是产品定位的精准切割。

一位在快消行业做数据架构的读者留言：「我带过十几个新人，发现学得快的不是背函数多的，而是先搞懂CALCULATE上下文切换的。那个顿悟时刻之后，看其他函数都像看说明书。」

你收藏夹里那个200函数的DAX速查表，最后一次打开是什么时候？