DAX权威指南：从计算上下文到CALCULATE，彻底搞懂Power BI公式语言

简介：《DAX权威指南》第二版英文原版PDF，由Marco Russo与Alberto Ferrari合著、微软授权Pearson出版，面向数据分析师、商业智能开发者及使用Power BI、SQL Server Analysis Services与Excel构建分析方案的技术人员。全书从DAX基础语法讲起，深入数据模型与表间关系、CALCULATE与FILTER等核心函数、计算列与迭代表达式，并覆盖多对多关系、上下文转换、查询性能优化与最佳实践，配有多个真实案例，适合希望系统掌握DAX建模与计算的初中级读者进阶。资源包共1个PDF文件，大小约13.03MB，为完整电子书正文，便于离线阅读与按章节检索。目前已有827人学习下载，可作为日常查阅DAX函数语义与建模思路的案头参考。

1. 到底什么是 DAX：一个让 Excel 老手也发懵的公式语言

如果你用过 Excel，大概率写过=SUM(A1:A10)这种公式，鼠标一拖，结果就出来了。但当你第一次打开 Power BI，想算一个「销售额占比」，搜到的答案里赫然出现CALCULATE、FILTER、ALL这些词，公式长得像天书，写完还报错——这时候你遇到的，就是 DAX。

DAX 全称 Data Analysis Expressions，中文一般叫「数据分析表达式」。通俗地说，它是一门专门用来在数据模型上做计算的公式语言，主要活跃在 Microsoft Power BI、SQL Server Analysis Services 表格模型和 Excel 的 Power Pivot 里。它和 Excel 公式长得像亲戚，骨子里却是两套逻辑：Excel 算的是单元格，DAX 算的是表和列。这份《DAX 权威指南》第二版原版 PDF，就是把这个「看着像 Excel、用起来完全不是一回事」的语言，从基础语法一路讲到查询计划优化的完整参考书。搞懂它，你才算真正摸到了 Power BI 计算能力的门槛。

2. DAX 为什么让人又爱又恨：它到底解决了什么问题

2.1 从「单元格思维」切换到「表思维」

Excel 用户最熟悉的动作是：选中一个格子，写公式，往下拖。每个格子有自己的公式，算的是自己那一行。DAX 不是这样。DAX 的公式写在「度量值」里，一个度量值只有一份定义，却要在你拖进图表的每一个维度组合下都算出正确结果。换句话说，你写的不是「这一格等于什么」，而是「这一类格子都该怎么算」。

打个比方：Excel 像是你亲手给每个学生写一张成绩单，DAX 像是你写一套评分规则，然后学校按班级、按科目、按学期自动套用这套规则生成所有成绩单。规则只有一份，但要在无数种筛选组合下都成立——这就是 DAX 的核心难点，也是它强大的地方。

书里第 1 章专门对比了 DAX 对 Excel 用户、SQL 开发者、MDX 开发者的不同心智模型。对 Excel 用户，最大的坎是「单元格 vs 表」；对 SQL 开发者，最大的坎是「DAX 是函数式语言，不是声明式查询」；对 MDX 开发者，则是「多维模型 vs 表格模型」的差异。认清自己从哪来，才知道该补哪块认知。

2.2 它为什么必须存在：计算要跟着筛选走

有人会问：Excel 公式也能算占比、算同比，为什么还要另造一门语言？原因在于数据模型的规模和使用方式变了。当你的数据是几百万行、几十张关联表，用户还要在报表上随意切片、钻取、交叉筛选时，传统「一格一公式」的模式根本撑不住——你不可能为每一种筛选组合预先写好公式。

DAX 的设计思路是：把「当前筛选环境」作为计算的隐含输入。同一个[销售额]度量值，放在「按年份」的图里算的是年度销售，放在「按地区」的表里算的是地区销售，公式一个字没改。这种「计算随上下文自动变化」的能力，是 DAX 存在的根本理由，也是它区别于普通公式语言的关键特征。

2.3 函数库不是重点，上下文才是

初学者常有的错觉是：DAX 难在函数多。其实书里第 2 章把常用函数按聚合、逻辑、信息、数学、文本、转换、日期时间、关系分门别类讲了一遍，真正需要死记的并不多。难的是第 4 章和第 5 章讲的「计算上下文」——筛选上下文和行上下文，以及CALCULATE触发的上下文转换。

可以这样理解：函数是词汇，上下文是语法。词汇查手册就有，语法错了句子就不通。很多人 DAX 写不对，不是不知道SUMX怎么用，而是没搞清「我现在处在哪种上下文里、这个上下文是怎么来的」。这本书把上下文单独拎出来讲了两大章，正是因为它值得。

提示：如果你只记一件事，就记「DAX 的计算结果 = 表达式 + 当前上下文」。表达式写在明处，上下文藏在暗处，出问题多半是暗处那半。

3. 把 DAX 拆开看：几个必须分清的核心概念

3.1 计算列和度量值：一个存下来，一个算出来

这是初学者第一个高频翻车点。计算列是在数据表里新增一列，公式对每一行求值，结果会真实存进模型、占用内存；度量值不存结果，只存公式，在你把它拖进视觉对象时才按当前筛选实时计算。

书里第 2 章用「计算列 vs 度量值」做了明确区分。判断标准其实很朴素：如果你要的是「每一行自己的属性」，比如给每笔订单标出「单价 × 数量」的金额，用计算列；如果你要的是「当前筛选下的汇总」，比如「所选地区的总销售额」，用度量值。把汇总逻辑写进计算列，是新手最常见的错误之一，结果往往是数字对不上，还找不到原因。

3.2 行上下文和筛选上下文：两种「当前范围」

行上下文（row context）出现在计算列和迭代函数里，意思是「我正在逐行处理，当前这一行是谁」。筛选上下文（filter context）出现在报表的筛选器、切片器、视觉对象的行列上，意思是「当前这次计算，哪些数据被选中了」。

两者的关系是 DAX 最烧脑的部分。行上下文不会自动变成筛选上下文，除非你用了CALCULATE——这就是「上下文转换」。书里第 5 章用大量篇幅讲这个机制，因为它是理解CALCULATE行为的钥匙。通俗地说：行上下文是「我在看这一行」，筛选上下文是「整个模型现在只剩这些行」，CALCULATE的作用就是把前者翻译成后者。

3.3 CALCULATE：DAX 里最值得单独学的一个函数

如果 DAX 只能学一个函数，那一定是CALCULATE。它的作用是「在修改后的筛选上下文里计算一个表达式」。所有「占比」「同比」「占整体比例」「忽略某个筛选」的需求，几乎都要经过它。

-- 计算所选产品占全部产品销售额的比例 Sales Pct of All = DIVIDE ( [Sales Amount], -- 当前筛选上下文下的销售额 CALCULATE ( [Sales Amount], -- 同一个度量值 ALL ( Product ) -- 但先移除 Product 表上的所有筛选 ) )

这段代码里，分子跟着报表筛选走，分母用ALL(Product)清掉了产品维度的筛选，于是得到「当前产品 / 全部产品」的比例。DIVIDE相比直接用/的好处是能处理除零，返回空白而不是报错。参数上，CALCULATE第一个参数是要计算的表达式，后面可以跟任意多个筛选修饰符，ALL、KEEPFILTERS、USERELATIONSHIP、CROSSFILTER都属于这一类。书里第 5 章把这些修饰符逐个拆开讲，还专门讨论了CALCULATE内部的求值顺序——这个顺序搞不清，嵌套CALCULATE就会写出「玄学」结果。

3.4 变量 VAR：让长公式能读、能调、不重复算

DAX 公式一长就容易变成「括号地狱」。VAR语法允许你把中间结果命名，后面直接引用。书里第 6 章强调了两点：变量是常量，一旦赋值不会随上下文再变；变量有作用域，只在定义它的表达式内可见。

-- 用变量拆解「高价值客户销售额」 High Value Sales = VAR CustomerSales = [Sales Amount] -- 先算出当前上下文销售额 VAR Threshold = 10000 -- 设定阈值 RETURN CALCULATE ( [Sales Amount], FILTER ( VALUES ( Customer[Name] ), [Sales Amount] > Threshold ) )

变量的价值不只是好看，它还能避免同一段逻辑被重复计算，对性能有实际影响。书里还提到「惰性求值」：变量不是定义时就执行，而是在真正被引用时才计算，这一点在写复杂度量值时会影响你对执行顺序的判断。

3.5 迭代函数：SUMX 和 SUM 差在哪

SUM是对一列直接求和，SUMX是先逐行算一个表达式、再把结果加起来。差别在于SUMX带有行上下文，可以在里面引用多列、调用其他函数。书里第 7 章讲迭代器时特别提醒「基数」问题：迭代表越大，逐行计算的成本越高，能不用迭代就不用，非用不可时要留意性能。

一个典型例子是「销售额 = 单价 × 数量」的汇总。如果表里没有现成的金额列，就得用SUMX(Sales, Sales[Price] * Sales[Quantity])。这里的乘法发生在每一行的行上下文里，SUMX负责把每行结果累加。理解了这个模式，后面遇到AVERAGEX、MAXX、CONCATENATEX都是同一套逻辑。

4. 容易混淆的几个概念：别在这些地方栽跟头

4.1 易混点一：CALCULATE 和 FILTER 都能「筛选」，但不是一回事

很多人以为CALCULATE里套FILTER和直接写筛选条件等价。实际上，CALCULATE的筛选参数如果是布尔表达式，会走简化的单列筛选；而FILTER返回的是一张表，作为筛选参数时会替换掉对应表上的原有筛选，行为更重、更容易影响性能。区分方法：条件只涉及单列且是简单比较，优先用CALCULATE直接写条件；需要跨列、需要引用度量值做行级判断时，才用FILTER。

4.2 易混点二：ALL 和 ALLSELECTED 看着像，语义差很远

ALL是「移除所有筛选」，ALLSELECTED是「移除当前视觉对象内部的筛选，但保留外部切片器的选择」。做「占所选范围的比例」时用ALLSELECTED，做「占全表比例」时用ALL。混用会导致分母范围不对，报表数字看着合理、实际全错。书里第 3 章和第 5 章都反复提到这一对，值得单独记一笔。

4.3 易混点三：关系方向决定筛选能不能「传过去」

数据模型里的关系有方向。一对多关系中，筛选通常从「一」端流向「多」端。如果你在「多」端放筛选器，却期望它影响「一」端的计算，默认是传不过去的，需要CROSSFILTER调整。初学者常把「表连上了」等同于「筛选互通」，这是两件事。书里第 15 章专门讲高级关系，包括多对多和双向筛选的代价。

4.4 易混点四：计算列里的 SUM 和度量值里的 SUM 结果可能不同

在计算列里写SUM(Sales[Amount])，因为没有筛选上下文，往往算的是整表合计，然后每一行都得到同一个数——这通常不是你想要的结果。度量值里的SUM才会跟随报表筛选变化。区分方法：问自己「这个结果应该随切片器变吗」，答案是「应该」就放度量值。

4.5 易混点五：时间智能函数不是万能钥匙

TOTALYTD、SAMEPERIODLASTYEAR这类函数依赖一张标记为日期表的连续日期表。没有正确标记日期表，函数会报错或给出莫名其妙的结果。这不是函数本身的问题，是模型准备没做到位。书里第 8 章讲时间智能时，前置条件讲得比函数用法还细，原因就在这里。

5. 什么时候该翻这本书，什么时候先放一放

先说该用的时候。如果你已经在 Power BI 或 Excel Power Pivot 里写过一些度量值，能跑通简单汇总，但一遇到「占比不对」「同比算出来是空白」「CALCULATE 嵌套后结果玄学」就卡住，那这本书正好补上你缺的那层理论。它把上下文、上下文转换、CALCULATE求值顺序这些「黑匣子」拆开给你看，看完再回头调公式，很多血泪经验就不用自己踩一遍。书的后半部分（第 17 到 20 章）讲 DAX 引擎、VertiPaq 优化和查询计划分析，适合已经能写对公式、开始关心「为什么慢」的人。

再说先放一放的时候。如果你连 Power BI 的基本操作都没摸过，表关系怎么建、视觉对象怎么放还不熟，直接啃这本 700 多页的英文原版会非常吃力——它假设你已经知道什么是数据模型、什么是度量值。另外，如果你只是偶尔做一张简单报表，SUM加几个切片器就够用，那暂时不需要系统学 DAX，遇到具体问题查函数文档效率更高。

下面这张表可以帮你快速判断自己处在哪个阶段：

我自己的习惯是：每次写CALCULATE之前，先在心里默念一遍「当前筛选上下文是什么、我要改哪部分、改完影响谁」，三步走完再动手。这个习惯帮我省掉了大量「数字看着对、其实全错」的返工。希望帮到你。

本文还有配套的精品资源，点击获取