简介《DAX权威指南》第二版英文原版PDF由Marco Russo与Alberto Ferrari合著、微软授权Pearson出版面向数据分析师、商业智能开发者及使用Power BI、SQL Server Analysis Services与Excel构建分析方案的技术人员帮助系统掌握DAX数据建模与计算语言。全书从DAX基础语法、表函数与求值上下文讲起深入CALCULATE、SUMX、FILTER等核心函数、表间关系与多对多建模、上下文转换等高级特性并覆盖查询性能优化、最佳实践与真实案例研究兼顾入门理解与进阶提升。资源包共1个PDF文件约13.03MB内容完整、便于离线查阅与检索。目前已有827人学习下载适合希望深入理解DAX核心概念、提升复杂业务分析效率的读者作为长期参考手册。1. 为什么 DAX 的“难”不在函数而在上下文很多人第一次写 DAX都会经历同一个瞬间函数名都认识语法也没报错但结果就是不对。SUM 明明求和了为什么放进度量值里就变了FILTER 明明筛了为什么换张表就失效这不是你函数背得不够而是 DAX 的执行模型和你熟悉的 Excel、SQL 根本不是一回事。DAXData Analysis Expressions是 Power BI、SQL Server Analysis Services 表格模型和 Excel 数据模型共用的建模语言它真正难的地方从来不是函数库有多庞大而是求值上下文这套隐式机制——行上下文和筛选上下文如何生成、如何传播、如何在 CALCULATE 里发生转换。搞不懂这层写出来的公式就是玄学搞懂了你才知道每一行结果到底是怎么被算出来的。这份《DAX 权威指南》第二版把上下文、CALCULATE、变量、迭代器、查询计划一路拆到引擎层正好是补这块底层认知的材料。2. 求值上下文一行公式的结果到底由谁决定DAX 里任何一个表达式求值都不是孤立发生的。它总是处在某个“上下文”里上下文决定了当前可见的数据行和列值。理解这一点是从“会写函数”跨到“能预测结果”的分水岭。书里把上下文拆成两种行上下文row context和筛选上下文filter context两者来源不同、作用范围不同混用就是大多数翻车的起点。2.1 行上下文迭代时“当前这一行”是怎么被绑定的行上下文只在迭代场景里出现。当你写SUMX(Sales, Sales[Amount] * Sales[Quantity])SUMX 会逐行遍历 Sales 表每遍历到一行就为这一行建立一个行上下文让Sales[Amount]和Sales[Quantity]能解析成“当前行”的值。它本质上是迭代器在循环时临时绑定的一层“当前行指针”。关键点在于行上下文不会自动筛选模型里的其他表。它只让当前表的列能被直接引用不会顺着关系去过滤关联表。这是它和筛选上下文最本质的区别也是新手最容易误解的地方——以为在计算列里写了Sales[Amount]关联的产品表就自动被限定了其实没有。-- 计算列行上下文只绑定当前行不筛选其他表 Sales[LineTotal] Sales[Amount] * Sales[Quantity] -- 迭代器SUMX 为每一行建立行上下文 TotalRevenue SUMX( Sales, Sales[Amount] * Sales[Quantity] -- 这里的列引用走行上下文 )上面第一段是计算列行上下文由引擎在物化该列时逐行建立第二段是度量值里的迭代器行上下文由 SUMX 在遍历时建立。两处的列引用都靠行上下文解析但都不会触发对产品表、日期表的筛选。参数上SUMX 的第一个参数是待迭代表的表达式第二个参数是对每一行求值的标量表达式返回所有行结果之和。理解这个“只绑定、不筛选”的语义后面看上下文转换才不会懵。2.2 筛选上下文报表里的切片器是怎么变成一堵“可见数据墙”的筛选上下文来自报表层的交互切片器、行列表头、列列表头、页面筛选器以及 CALCULATE 显式构造的筛选条件。它决定了在当前单元格里每张表的哪些行是“可见”的。你在矩阵里放一个“产品类别”行每个类别单元格就带着一个“该类别”的筛选上下文度量值只在这个可见子集上计算。筛选上下文会顺着关系传播而且默认是单向的从一对多关系的“一”端流向“多”端。产品表被筛到某个类别销售表里属于该类别的行才可见。反过来销售表的筛选不会自动回传到产品表除非关系被配置成双向交叉筛选。这个方向性设计是为了避免歧义和循环但也意味着你写公式时必须清楚当前这个筛选到底能不能传到我想算的那张表。-- 度量值在报表筛选上下文下计算可见行的销售额 Total Sales SUM( Sales[Amount] ) -- 同一度量值在不同单元格里结果不同 -- 因为每个单元格的筛选上下文不同类别、年份、地区……Total Sales本身没有任何筛选逻辑它的结果完全由外部筛选上下文决定。这就是为什么同一个度量值拖到不同维度下会给出不同数字——不是公式变了是上下文变了。我一般会这么理解度量值是“函数”筛选上下文是“实参”报表每渲染一个单元格就是拿一组新的实参调用一次。2.3 两种上下文为什么必须分开设计把行上下文和筛选上下文做成两套独立机制不是冗余而是职责分离。行上下文解决“迭代时如何引用当前行的列”是逐行计算的基础筛选上下文解决“当前可见哪些数据”是聚合与切片的基础。二者来源不同一个来自迭代器一个来自报表或 CALCULATE。分开设计带来的直接好处是你可以在没有筛选上下文的地方比如计算列做逐行运算也可以在需要动态筛选的地方比如度量值精确控制可见集。代价是二者不会自动互通——行上下文不会变成筛选上下文除非你显式用 CALCULATE 触发上下文转换。这个“不自动”正是很多公式失效的根源也是下一章要拆的核心。3. CALCULATE 与上下文转换DAX 最反直觉的那一步如果只允许记一个 DAX 函数那一定是 CALCULATE。它不是普通的聚合函数而是唯一能修改筛选上下文的函数也是上下文转换的触发器。书里花了整整一章讲它因为几乎所有“为什么结果不对”的问题最后都能追到 CALCULATE 的行为上。3.1 CALCULATE 做了什么先改筛选再求值CALCULATE 的语义可以概括成三步接收一个表达式和若干筛选参数用这些参数替换或叠加当前筛选上下文在新的筛选上下文下对表达式求值。它的筛选参数会覆盖同一列上已有的筛选不同列则取交集。-- 计算所有产品忽略当前类别筛选的销售额 All Product Sales CALCULATE( [Total Sales], ALL( Product ) -- 移除产品表上的所有筛选 ) -- 计算特定颜色红色的销售额覆盖当前颜色筛选 Red Sales CALCULATE( [Total Sales], Product[Color] Red )第一段用ALL(Product)清掉产品表上的筛选于是[Total Sales]在“全部产品”的上下文里求值得到总计。第二段用Product[Color] Red覆盖颜色列上的现有筛选。参数上第一个参数是被求值的表达式后续参数是筛选器可以是布尔条件、表表达式或 ALL 系列函数。注意ALL返回的是一张去掉筛选的表CALCULATE 把它当作“移除这些列的筛选”来用而不是“筛选到这些行”。3.2 上下文转换行上下文如何“变成”筛选上下文这是 DAX 里最反直觉、也最容易被忽略的一步。当 CALCULATE 在一个行上下文里被调用时它会把当前行的每一列值转换成对应列上的等值筛选叠加到筛选上下文里。这个过程叫上下文转换context transition。-- 计算列为每行算出该客户的历史总销售额 Customer Total CALCULATE( SUM( Sales[Amount] ) -- 这里会触发上下文转换 )这段代码看起来什么都没筛但结果却是“当前客户的总销售额”。原因在于计算列本身处在行上下文里CALCULATE 被调用时把当前行的客户 ID 等列值转成了筛选条件于是SUM(Sales[Amount])只在“当前客户”的销售行上求和。如果没有 CALCULATESUM会忽略行上下文直接对整列求和结果每行都一样——这就是很多人第一次写计算列时“每行结果相同”的翻车现场。上下文转换的规则是行上下文里当前行的所有列都会被转成筛选不只是你显式引用的那一列。这在宽表上可能带来额外开销也可能引入你没意识到的筛选。常见的实现思路是引擎在转换时对当前行做一次“行值到筛选”的映射再与已有筛选上下文合并。理解这一点你就能解释为什么某些计算列慢、为什么某些度量值在迭代器里结果异常。3.3 KEEPFILTERS、USERELATIONSHIP、CROSSFILTER修饰符解决的具体问题CALCULATE 的筛选参数默认是“覆盖”语义但有些场景你需要“叠加”而不是覆盖这就需要修饰符。KEEPFILTERS让新筛选与已有筛选取交集而不是替换USERELATIONSHIP在计算时临时启用某条非活动关系CROSSFILTER临时改变关系的交叉筛选方向。-- 保留外部对颜色的筛选只在其基础上再限定红色 Red With Keep CALCULATE( [Total Sales], KEEPFILTERS( Product[Color] Red ) ) -- 用非活动关系如发货日期计算销售额 Sales By Ship Date CALCULATE( [Total Sales], USERELATIONSHIP( Sales[ShipDate], Date[Date] ) )KEEPFILTERS的意义在于如果外部已经筛了“蓝色”默认的Product[Color] Red会覆盖成红色得到红色销售额加上 KEEPFILTERS 后红蓝交集为空结果为空——这才是“在当前筛选基础上再限定”的正确语义。USERELATIONSHIP解决的是同一张表对日期维度有多条关系下单日期、发货日期时默认只有一条活动关系的问题。参数是关系两端的列调用期间该关系被临时激活。这些修饰符不是语法糖而是对筛选传播行为的精确控制用错一个结果就悄悄偏了。4. 变量与迭代器让复杂公式可读、可预测、可优化DAX 公式一长就容易变成嵌套地狱读的人不知道哪层算的是什么写的人自己也容易算重复。变量VAR和迭代器的正确组合是让公式从“能跑”到“可维护、可优化”的关键。书里把变量、迭代器、上下文转换放在相邻章节正是因为它们经常一起出现。4.1 VAR 是常量一次求值多处复用VAR 定义的值在定义时求值一次之后在整个表达式里作为常量复用不会因为引用多次而重复计算。这个特性既提升可读性也避免重复扫描。-- 用变量拆解避免重复计算和嵌套 Sales Growth % VAR CurrentSales [Total Sales] VAR PreviousSales CALCULATE( [Total Sales], SAMEPERIODLASTYEAR( Date[Date] ) ) VAR Result DIVIDE( CurrentSales - PreviousSales, PreviousSales ) RETURN Result这里CurrentSales和PreviousSales各算一次Result复用它们。如果没有变量你得把两个表达式各写两遍不仅难读还可能因为上下文细微差异导致两次计算结果不一致。参数上VAR 后跟变量名和表达式RETURN 后跟最终返回的表达式变量作用域限于当前表达式不能跨度量值共享。注意 VAR 是常量语义它捕获的是定义时的上下文不会随后续上下文变化而重新求值——这一点在迭代器里尤其重要。4.2 迭代器基数SUMX 慢往往慢在“行数 × 每行开销”迭代器SUMX、AVERAGEX、MAXX 等对表的每一行求值再聚合开销和表的基数行数成正比。书里专门讲迭代器基数是因为性能问题经常出在这里一个在百万行表上逐行调用 CALCULATE 的迭代器可能触发百万次上下文转换每次转换都要做行值到筛选的映射。-- 高开销写法逐行调用度量值触发大量上下文转换 Expensive Total SUMX( Sales, [Total Sales] -- 每行都触发一次上下文转换 ) -- 较低开销写法直接在行上下文里做标量运算 Cheaper Total SUMX( Sales, Sales[Amount] * Sales[Quantity] )第一段在 Sales 的每一行上调用[Total Sales]每次调用都触发上下文转换开销随行数线性增长。第二段只做标量乘加不触发转换快得多。这不是说第一种写法永远不能用而是你要清楚它的代价当迭代器基数很大时优先考虑能否把度量值展开成行内标量运算或者先用 FILTER 缩小基数再迭代。我一般会这么判断迭代器里出现度量值调用就要警惕基数。4.3 惰性求值与表变量什么时候算、算几次变量支持表类型VAR t FILTER(...)会把一张表存进变量。这里有个容易踩的点表变量的求值时机和上下文捕获。变量在定义时求值捕获的是定义处的上下文如果定义处没有你期望的筛选后面再用也不会补上。-- 表变量捕获定义时的上下文 Top Products VAR TopN TOPN( 10, ALL( Product[ProductName] ), [Total Sales], DESC ) RETURN CALCULATE( [Total Sales], TopN )TopN在定义时基于当前上下文算出前 10 名产品存成表变量CALCULATE再用它作为筛选参数。注意ALL(Product[ProductName])显式清除了产品名上的筛选否则 TOPN 只在当前可见产品里选结果会随单元格变化。表变量的价值在于把“算一次、用多次”的逻辑固化下来减少重复扫描代价是它可能物化中间结果占用内存。惰性求值意味着引擎可能推迟实际计算但语义上变量仍是定义时求值不要依赖“用到才算”来规避上下文问题。5. 常见问题与排查那些让结果悄悄偏掉的坑DAX 最折磨人的地方是公式不报错、结果却不对。下面几条是我在排查时反复遇到的按“现象 → 原因 → 解决”记下来能省不少时间。5.1 计算列每行结果都一样现象新建计算列写了个聚合整列值完全相同。原因聚合函数忽略行上下文直接对整列求和没有触发上下文转换。解决用 CALCULATE 包裹聚合让行上下文转换成筛选例如CALCULATE(SUM(Sales[Amount]))或者改用迭代器显式逐行计算。5.2 度量值放进迭代器后结果翻倍或异常现象同一个度量值单独用正常放进 SUMX 后数字偏大。原因迭代器为每行建立行上下文度量值里的 CALCULATE 触发上下文转换叠加了额外筛选导致重复或错位聚合。解决确认迭代器是否真的需要调用度量值能展开成行内标量运算就展开必须调用时先用 FILTER 缩小基数并检查转换引入的列筛选是否符合预期。5.3 关系筛选传不过去现象在产品表上筛了类别销售表度量值却没变化。原因关系方向是单向的筛选只从“一”端流向“多”端或者关系未激活。解决检查关系方向必要时用 CROSSFILTER 临时改方向或用 USERELATIONSHIP 激活非活动关系同时确认筛选列确实在关系的“一”端。5.4 ALL 用错位置总计对但明细错现象占比类度量值在总计行正确明细行却不对。原因ALL 清除了过多列的筛选或者放在了不该放的位置导致分母口径和分子不一致。解决用 ALLSELECTED 保留外部筛选、只清除内部筛选或者精确指定 ALL 的列避免整表清除。占比公式里分子分母的上下文要对称。5.5 变量捕获了错误的上下文现象把一段逻辑抽成 VAR 后结果和原来不一致。原因变量在定义时求值捕获的是定义处的上下文而不是使用处的上下文。解决把 VAR 定义放在正确的上下文位置或者把需要动态求值的部分留在 RETURN 后的表达式里不要提前固化。6. 从公式到引擎查询计划与 VertiPaq 决定了性能上限写到一定程度你会发现公式层面的优化有天花板真正的性能差异来自引擎怎么执行你的 DAX。书的后半部分讲 DAX 引擎、VertiPaq 存储、查询计划和优化这部分是把“会写”推到“写得快”的关键。6.1 存储引擎与公式引擎一次查询的两段式执行DAX 查询通常分两段公式引擎Formula Engine负责解析表达式、管理上下文、做逐行运算存储引擎Storage Engine负责从 VertiPaq 列式存储里扫描和聚合数据。公式引擎是单线程的存储引擎可以并行。性能问题的常见形态是公式引擎做了太多本可以下推给存储引擎的工作比如在迭代器里逐行调用复杂表达式导致大量小规模扫描。-- 公式引擎逐行处理存储引擎扫描次数多 Slow SUMX( VALUES( Sales[CustomerKey] ), CALCULATE( SUM( Sales[Amount] ) ) ) -- 更可能被下推为一次扫描聚合 Faster SUM( Sales[Amount] )第一段按客户逐个 CALCULATE公式引擎要协调多次上下文转换和扫描第二段是单次聚合存储引擎可以高效完成。判断标准是能否把筛选和聚合表达成存储引擎能直接执行的形态减少公式引擎的逐行协调。6.2 查询计划怎么读先看哪里慢再看为什么慢查询计划query plan会显示逻辑计划和物理计划物理计划里的运算符告诉你数据是怎么被扫描、连接、聚合的。排查时先定位耗时最长的运算符再看它是不是因为上下文转换、回调callback或大量小扫描而变慢。常见的信号是出现大量 CallbackDataID 之类的逐行回调说明公式引擎在逐行向存储引擎要数据这种模式在大基数上会很慢。6.3 VertiPaq 优化列式存储喜欢什么、讨厌什么VertiPaq 是列式内存存储压缩率高、扫描快但它对列的基数敏感高基数列如订单号、时间戳压缩效果差、占用内存大。优化方向包括去掉不需要的高基数列、把高基数事实列换成低基数代理键、避免在模型里保留无用的明细列。这些取舍不是公式能解决的而是建模阶段就要决定的。优化对象常见问题处理方向高基数列压缩差、内存高移除或替换为代理键关系方向单向导致筛选传不过去评估双向或 CROSSFILTER迭代器基数逐行转换开销大缩小基数或展开标量运算计算列物化占内存能放度量值就不放计算列这张表不是清单而是排查时的思考顺序先看存储层有没有明显浪费再看关系方向是否合理最后才回到公式层的迭代器和计算列。很多时候改模型比改公式收益大得多。我自己的习惯是任何新度量值上线前先在明细和大基数场景各跑一次看查询计划里有没有意外的逐行回调有就先改结构而不是急着调函数。DAX 的性能问题很少是某一个函数写错多半是上下文和引擎执行方式没对齐。希望这份材料能帮你把公式背后的机制看清楚少走几次“结果不对但不知道错在哪”的弯路。本文还有配套的精品资源点击获取