简介：《DAX权威指南》第二版英文原版PDF，由Marco Russo与Alberto Ferrari合著、微软授权Pearson出版，面向数据分析师、商业智能开发者及使用Power BI、SQL Server Analysis Services与Excel构建分析方案的技术人员，帮助系统掌握DAX数据建模与计算语言。全书从DAX基础、表函数与求值上下文讲起，深入CALCULATE、SUMX、FILTER等核心函数、表间关系与多对多建模、上下文转换等高级特性，并覆盖查询性能优化、最佳实践与真实案例研究，兼顾入门理解与进阶提升。资源包共1个PDF文件，大小约13.03MB，内容完整、便于本地检索与离线阅读。目前已有827人学习下载，适合希望从语法入门走向模型设计与性能调优的读者按章节精读并反复查阅。
1. 为什么 DAX 的“简单公式”总在关键时刻翻车
写过 Power BI 度量值的人大概都有过这种体验：一个看起来平平无奇的SUM(Sales[Amount])放进矩阵里，数字对得上；可一旦换成SUMX套FILTER，或者把度量值塞进另一个度量值里做占比，结果就开始飘——要么总数对、明细错，要么切片器一动就全乱。这不是玄学，而是 DAX 的求值上下文在背后悄悄换了规则。DAX（Data Analysis Expressions）是 Power BI、SQL Server Analysis Services 表格模型和 Excel 数据模型共用的建模与查询语言，它和 Excel 公式最大的区别在于：公式不是绑在某个单元格上，而是绑在一张表、一个筛选环境里，由引擎在查询时动态决定“当前看到哪些行”。搞不懂这套上下文机制，写 DAX 就只能靠试，试对了不知道为什么对，试错了也不知道错在哪。这份《DAX 权威指南》第二版把上下文、CALCULATE、上下文转换、迭代器、查询计划这些底层机制拆得很细，正好是补这块认知的原料。
2. 求值上下文：DAX 所有“意外结果”的总开关
DAX 里几乎每一个让人困惑的现象，追到根上都是两类上下文在起作用：筛选上下文（filter context）和行上下文（row context）。理解这两者的分工与交互，比背一百个函数都管用。
2.1 筛选上下文：查询时“当前能看到哪些行”
筛选上下文是 DAX 引擎在计算某个表达式时，施加在数据模型上的一组筛选条件集合。它不是一个静态的 WHERE 子句，而是随可视化对象的位置动态生成的：矩阵的一个单元格、切片器的一个选中项、图表的一个坐标轴刻度，都会往模型上叠一层筛选。度量值在计算时，看到的就是这些筛选叠加后的“可见数据子集”。
关键在于，筛选上下文是沿着关系传播的。假设有一个产品维度表和一个销售事实表，二者是一对多关系，从维度指向事实。当你在矩阵行上放产品类别时，引擎会对产品表施加“类别 = 某值”的筛选，然后这个筛选沿着关系自动传到事实表，把不属于该类别的销售行排除掉。这就是为什么你不需要在度量值里手写 JOIN——关系本身就是筛选传播的通道。
但传播是有方向的。默认的单向关系只从“一”端流向“多”端，反向不传播。很多人在事实表上放筛选、却发现维度表的计算没跟着变，就是踩了这个方向性的坑。书里专门用一章讲高级关系，包括双向交叉筛选和CROSSFILTER的适用边界，本质都是在回答“筛选该往哪个方向走”。
2.2 行上下文：迭代时“当前正在处理哪一行”
行上下文是另一套完全不同的机制。它出现在两种场景：计算列的定义中，以及迭代器函数（SUMX、FILTER、ADDCOLUMNS等）的表达式参数里。行上下文的作用很朴素——告诉引擎“现在正在处理表中的第 N 行”，于是你可以直接引用该行的列值。
-- 计算列：行上下文自动存在，直接引用本行列 Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice] -- 迭代器：SUMX 为每一行建立行上下文，再对表达式求值后累加 TotalRevenue = SUMX( Sales, Sales[Quantity] * Sales[UnitPrice] -- 这里的列引用依赖行上下文 )上面两段代码看起来做的事一样，但执行模型不同。计算列在数据刷新时逐行算好、物化存储，行上下文是“物理存在”的；而SUMX的行上下文是查询时临时建立的，每扫过一行就建一次、算一次、丢掉。这个差别直接决定了性能：计算列占内存但查询快，迭代器不占存储但每次查询都要重算。
行上下文还有一个容易被忽略的特性：它不会自动转成筛选上下文。也就是说，在SUMX的行上下文里直接写SUM(Sales[Amount])，那个SUM看到的不是“当前这一行”，而是整个筛选上下文下的全部可见行。这是新手最容易翻车的地方——以为在逐行算，其实聚合函数把整列又算了一遍。
2.3 两种上下文为什么必须分开设计
把筛选和行拆成两套机制，是 DAX 区别于 SQL 的核心设计取舍。SQL 里 WHERE 和 SELECT 的逐行表达式在同一个查询块里天然共存，因为 SQL 的执行计划由优化器统一编排。DAX 面对的是交互式分析场景：同一个度量值要在任意切片组合下即时重算，引擎无法预知用户会点哪个切片器，所以必须把“环境筛选”和“逐行计算”解耦，让筛选上下文由外部查询动态注入，行上下文由迭代器在内部按需建立。
这个解耦带来的直接后果，就是两种上下文之间需要一座桥——而这正是CALCULATE和上下文转换要解决的问题。书里把第 4 章整章用来讲求值上下文，第 5 章紧接着讲CALCULATE，这个编排顺序本身就是一条认知路径：先分清两种上下文，再理解它们如何互相转化。
3. CALCULATE 与上下文转换：DAX 最核心的那台发动机
如果说求值上下文是 DAX 的地基，那CALCULATE就是建在地基上的发动机。它只做两件事：修改筛选上下文，以及在特定条件下触发行上下文到筛选上下文的转换。但这两件事组合起来，撑起了 DAX 里绝大多数复杂计算。
3.1 CALCULATE 的求值顺序：先改环境，再算表达式
CALCULATE的签名是CALCULATE(<expression>, <filter1>, <filter2>, ...)。它的执行顺序有明确的规则：先对当前筛选上下文做一份拷贝，然后把后面每个筛选参数依次作用到这份拷贝上，最后在这个新环境里对表达式求值。注意，筛选参数是“替换”而非“叠加”同列上的已有筛选——这是CALCULATE和KEEPFILTERS的分水岭。
-- 忽略产品类别的现有筛选，强制算全部类别的销售额 AllCategorySales = CALCULATE( SUM(Sales[Amount]), ALL(Product[Category]) -- 移除 Category 上的筛选 ) -- 保留现有筛选，只额外要求颜色为 Red（交集语义） RedSales = CALCULATE( SUM(Sales[Amount]), KEEPFILTERS(Product[Color] = "Red") )第一段里ALL把类别筛选清掉，所以无论矩阵行上放什么类别，结果都是全局总额——这是算占比分母的标准写法。第二段用KEEPFILTERS包住条件，语义从“替换”变成“取交集”，如果当前上下文已经筛了蓝色，结果就是空。这两种语义的差别，书里用一整节讲KEEPFILTERS，因为它是很多“数字突然变空”问题的根源。
筛选参数还有一层细节：当参数是一个表表达式（比如FILTER(Product, ...)）时，CALCULATE会把这个表表达式的结果当作新的筛选条件，覆盖对应列上的旧筛选。而当参数是布尔表达式（如Product[Color] = "Red"）时，引擎会自动把它包装成对相应列的筛选。这两种写法在简单场景下等价，但在复杂条件、多列组合时会表现出不同的行为，尤其是涉及空值和关系传播时。
3.2 上下文转换：行上下文如何“变成”筛选上下文
上下文转换是 DAX 里最反直觉、也最值得吃透的机制。它的规则只有一句话：当行上下文存在时，CALCULATE（以及所有内部调用CALCULATE的函数，比如度量值引用）会把当前行的每一列值，转成对该列的等值筛选，叠加到筛选上下文上。
-- 在 Sales 表的计算列里引用度量值，触发上下文转换 Sales[CategoryShare] = VAR CurrentAmount = Sales[Amount] -- 行上下文：当前行的值 VAR CategoryTotal = CALCULATE( SUM(Sales[Amount]), ALL(Sales) -- 先清掉 Sales 上的筛选 ) RETURN DIVIDE(CurrentAmount, CategoryTotal)这段代码里，CALCULATE执行时，当前行的所有列值（包括产品键、日期键等）都会被转成筛选条件。如果不清掉，SUM就只会算当前这一行，结果永远是 1。所以必须用ALL(Sales)把行上下文转换来的筛选清掉，才能得到“当前行所属类别/产品的总额”。这个“先转换、再清除”的顺序，是理解上下文转换的关键。
上下文转换在度量值引用时同样生效。当你在一个迭代器里引用另一个度量值，引擎会为每一行建立行上下文，然后度量值内部的CALCULATE把该行转成筛选，于是度量值算的是“这一行对应的聚合值”。这就是为什么SUMX(Sales, [SomeMeasure])能逐行算出不同的结果——[SomeMeasure]每次被调用时，看到的筛选环境都不一样。
3.3 循环依赖：上下文转换的暗礁
上下文转换带来灵活性的同时，也埋了一个坑：循环依赖。当计算列 A 引用了依赖 A 的度量值，或者两个计算列通过上下文转换互相引用时，引擎会检测到依赖环并报错。书里专门讲了循环依赖的判定逻辑，核心在于依赖关系是在“列级”而非“行级”追踪的——只要 A 的表达式里出现了对 B 的引用，而 B 又直接或间接引用 A，就构成环，跟运行时具体算哪一行无关。
规避的思路通常是打破引用链：把中间结果落到变量里、用CALCULATE显式控制筛选范围、或者把逻辑从计算列挪到度量值。我一般会这么理解：上下文转换是一把双刃剑，它让行级数据能参与聚合计算，但也让依赖关系变得隐式，写的时候要刻意让引用链保持单向。
4. 迭代器与变量：性能与正确性的双重博弈
DAX 里性能问题的高发区，几乎都集中在迭代器和变量的使用上。迭代器决定了“扫多少行、建多少次上下文”，变量决定了“算几次、什么时候算”。这两者配合得好，查询快且结果稳；配合得差，就是卡顿和错值的双重来源。
4.1 迭代器的基数：为什么 SUMX 有时比 SUM 慢几个数量级
SUM是聚合函数，直接在存储引擎层面扫列求和，不建立行上下文；SUMX是迭代器，要为表的每一行建立行上下文、对表达式求值、再累加。两者的性能差距取决于迭代的基数（cardinality）——也就是被迭代表的行数。
-- 聚合：存储引擎直接扫列，快 TotalQty = SUM(Sales[Quantity]) -- 迭代：逐行建上下文求值，基数大时明显变慢 TotalQtyX = SUMX(Sales, Sales[Quantity]) -- 迭代 + 上下文转换：每行还要触发一次 CALCULATE，代价更高 WeightedAvg = SUMX( Sales, Sales[Quantity] * RELATED(Product[Price]) -- RELATED 沿关系取值 )第三段里RELATED需要沿关系从产品表取价格，每一行都要做一次关系查找，基数上万时开销就很可观。书里讲迭代器基数时强调：能用聚合函数解决的，不要用迭代器；必须迭代时，尽量把不依赖行上下文的计算提到迭代器外面，用变量先算好。
4.2 变量的常量语义与惰性求值
DAX 的VAR有两个容易被误解的特性。第一，变量是常量：一旦赋值，后续引用不会因为上下文变化而重新计算。第二，变量是惰性求值的：只有在被引用时才真正计算，且只算一次。
-- 变量只算一次，后续多次引用复用结果 SalesGrowth = VAR CurrentSales = SUM(Sales[Amount]) VAR PreviousSales = CALCULATE( SUM(Sales[Amount]), SAMEPERIODLASTYEAR('Date'[Date]) ) RETURN DIVIDE(CurrentSales - PreviousSales, PreviousSales)这里CurrentSales和PreviousSales各算一次，DIVIDE里引用的是已经算好的值。如果不用变量、把SUM直接写进DIVIDE两次，引擎可能算两遍。变量不仅让代码可读，还能实质性地减少重复计算——这是性能优化里性价比最高的手段之一。
但惰性求值也有陷阱：如果变量定义了一个表表达式，而后续引用时上下文已经变了，变量不会重新按新上下文求值，因为它捕获的是定义时的环境。书里讲变量作用域时特别提醒，表变量在复杂筛选场景下要小心，必要时用CALCULATETABLE显式固定环境。
4.3 迭代器里套 CALCULATE：上下文转换的放大器
迭代器和CALCULATE组合时，上下文转换会在每一行触发一次，代价被基数放大。书里第 7 章专门讲这个组合，核心结论是：迭代器里的CALCULATE要尽量缩小转换范围，能用KEEPFILTERS限定的就别全表转换，能提前用变量算好的就别放进循环。
-- 不推荐：每行都做全表上下文转换 BadPattern = SUMX( Product, CALCULATE(SUM(Sales[Amount])) -- 每行转换 Product 全部列 ) -- 推荐：用变量固定分母，迭代只做轻量运算 BetterPattern = VAR TotalSales = SUM(Sales[Amount]) RETURN SUMX( Product, DIVIDE(CALCULATE(SUM(Sales[Amount])), TotalSales) )两段代码结果可能一样，但第二段把不依赖行上下文的TotalSales提到循环外，迭代内部只保留必要的转换，基数大时差距会非常明显。这类改写不改变语义，只改变求值次数，是 DAX 性能调优的常规操作。
5. 避坑与排查：那些让 DAX 结果“看起来对、其实错”的瞬间
DAX 最危险的地方不是报错，而是不报错但算错。下面几条是实际项目里反复出现的翻车现场，每条都按“现象 → 原因 → 解决”拆开。
5.1 占比分母用了 ALL 却忘了关系方向
现象：算某类别占全局的比例，分母用CALCULATE(SUM(Sales[Amount]), ALL(Product))，结果分母偏小，占比超过 100%。原因：ALL(Product)只清了产品表上的筛选，如果事实表上还有来自其他维度（比如日期）的筛选，这些筛选仍会通过关系传到事实表，分母并不是真正的全局总额。解决：确认分母要清哪些表的筛选，必要时用ALL(Sales)或REMOVEFILTERS()显式列出，别假设ALL一张表就万事大吉。
5.2 迭代器里直接写聚合函数，以为在逐行算
现象：SUMX(Sales, SUM(Sales[Amount]))的结果等于行数乘以总额，而不是逐行求和。原因：SUM是聚合函数，在行上下文里不会自动转成“当前行”，它看到的仍是整个筛选上下文。解决：逐行取值直接引用列（Sales[Amount]），需要聚合当前行所属分组时用CALCULATE触发上下文转换。
5.3 KEEPFILTERS 和普通筛选参数混用导致交集为空
现象：CALCULATE([Measure], Product[Color]="Red", KEEPFILTERS(Product[Size]="L"))在已筛选蓝色时返回空。原因：第一个参数替换了颜色筛选，第二个参数与现有尺寸筛选取交集，如果当前上下文尺寸不是 L，交集为空。解决：明确每个参数是替换还是交集语义，同一列上不要既替换又交集，必要时统一用KEEPFILTERS或统一用替换。
5.4 计算列引用度量值引发循环依赖
现象：新建计算列时报“检测到循环依赖”，但两个对象看起来没有直接互相引用。原因：计算列引用的度量值内部又通过上下文转换间接依赖了该计算列所在的表，形成隐式环。解决：把度量值逻辑改成不依赖该计算列的写法，或把计算列的逻辑挪到度量值层，切断引用链。
5.5 变量捕获了错误的上下文
现象：变量在CALCULATE外部定义，在内部引用时结果不符合预期。原因：变量在定义时按当时的上下文求值并固定，CALCULATE修改上下文后变量不会重算。解决：把变量定义挪到需要它的上下文内部，或用CALCULATETABLE在定义时就固定好筛选环境。
提示：排查 DAX 错值，先别急着改公式，先用一张最简单的矩阵把筛选上下文可视化出来——行放维度、列放度量值，逐层下钻看数字在哪一层开始偏，往往比读代码更快定位。
6. 从查询计划反推设计：DAX 引擎为什么这样取舍
把前面几章的机制串起来看，会发现 DAX 的很多“怪”设计，其实都是同一个约束下的必然结果：它要在一个交互式、任意切片组合的环境里，保证度量值能即时重算。这个约束决定了引擎必须把存储和计算分开——VertiPaq 负责列式压缩存储，公式引擎负责上下文管理和逐行求值，查询计划负责在两者之间调度。
书里第 17 到 20 章讲引擎和查询计划，是整本书最“底层”的部分。公式引擎处理的是上下文转换、迭代器、CALCULATE这些逻辑；存储引擎处理的是列扫描、聚合、关系查找这些物理操作。一个 DAX 查询慢，先要判断瓶颈在哪一侧：如果查询计划里大量出现对存储引擎的扫描且基数很高，问题在数据模型或筛选范围；如果公式引擎的回调次数过多，问题在迭代器和上下文转换的写法。
| 现象 | 大概率瓶颈 | 优先排查方向 |
|---|---|---|
| 切片器一动就卡 | 存储引擎扫描量大 | 模型关系、列基数、是否需要聚合表 |
| 单个度量值慢但数据量不大 | 公式引擎回调多 | 迭代器嵌套、上下文转换次数 |
| 刷新慢、查询快 | 计算列物化开销 | 计算列是否可改为度量值 |
| 查询计划里出现大量 Spooling | 迭代器物化中间结果 | 变量提前计算、减少重复迭代 |
这个表不是万能诊断，但它给了一个判断顺序：先看数据量和模型，再看公式写法，最后才动查询计划。很多人一上来就研究查询计划，结果发现只是关系方向配错了，白折腾。
设计取舍上，DAX 选择了“上下文由外部注入、计算由内部编排”的模型，代价是学习曲线陡、隐式行为多；收益是同一个度量值能在任意可视化组合下复用，不需要为每种切片写一份查询。这个取舍和 SQL 的“查询即计划”路线正好相反，也解释了为什么 SQL 老手转 DAX 最容易在上下文转换上栽跟头——SQL 里 JOIN 和 WHERE 是显式的，DAX 里关系传播和上下文转换是隐式的。
我自己的习惯是：每写一个带CALCULATE或迭代器的度量值，先在纸上画出“当前筛选上下文是什么、行上下文在哪一层、转换发生在哪一步”，画不清楚就不写。这个笨办法帮我省掉了大量事后排查的时间。这份第二版把上下文、CALCULATE、变量、迭代器、查询计划按认知顺序排下来，正好可以当一本机制手册反复翻——遇到错值先翻对应章节，比在网上搜零散答案靠谱得多。希望帮到你。
本文还有配套的精品资源，点击获取
