简介：《DAX权威指南》第二版英文原版PDF，是面向数据分析师、商业智能开发者和进阶Excel用户的DAX实战参考书，覆盖Microsoft Power BI、SQL Server Analysis Services与Excel三类主流BI工具中的数据建模与分析场景。全书从基础概念讲到高级应用，系统说明数据模型与表间关系、行上下文与筛选上下文、CALCULATE等关键函数、迭代器写法及复杂表达式设计，同时给出数据建模最佳实践与性能优化思路；通过多个实际案例研究演示如何排查常见错误、规避陷阱，并提供了可直接复用的公式片段与建模方法，能够帮助读者搭建完整的DAX知识框架，提升实际业务分析效率。资源为单个PDF文件，压缩包约13.03MB，便于下载后在电脑或平板上按章节学习。目前已有826人学习/下载，适合希望从原理到实践系统掌握DAX的读者深入研读。
1. 为什么DAX权威指南V2原版英文PDF会出现在每个分析师的收藏夹
DAX权威指南V2原版英文PDF，对很多数据分析师来说不是一个“读没读过”的问题，而是“什么时候开始认真读”的问题。刚接触Power BI和Excel Power Pivot时，大家都会写SUM、IF、CALCULATE，觉得DAX不过如此；等遇到滚动12个月毛利、按客户分组的留存率、跨表帕累托分析时，才发现自己写的度量值要么结果不对，要么报表一拖筛选器就卡死。这本书就是为这个阶段准备的：它不教你按钮怎么点，而是把DAX引擎的计算机制讲透。
V2指的是第二版，英文原版的价值在于术语和示例的原始一致性。中文版虽然读起来快，但DAX中大量概念词一旦经过翻译，和软件界面里的英文术语对不上，排查问题时反而多一道障碍。适合读这本书的人有两类：一类是已经在业务报表里写过几十个度量值、但经常在小计和同比上翻车的分析师；另一类是准备从Excel透视表迁到Power BI建模的数据岗。对纯零基础的人来说，这本书并不友好，建议先掌握基础操作再翻开。
2. 读V2之前先把三个底层概念装进脑子：筛选上下文、行上下文与上下文转换
很多读者拿到DAX权威指南V2后，直接从第一章刷到最后一章，结果前两章还觉得简单，一到CALCULATE、FILTER、ALL混在一起时就彻底卡住。问题不在于函数记不住，而在于脑子里没有建立DAX引擎的“空间感”。DAX里所有计算的起点，不是表，也不是行，而是上下文。下面三个概念是整本书的地基，先在地基上花两小时，后面能省两周的踩坑时间。
2.1 筛选上下文：所有度量值计算的起点
“筛选上下文”听起来抽象，其实就是报表当前状态下，一个度量值“看得见的行集合”。透视表里把月份放在行区域、把切片器选中某个区域时，这些外部操作都会自动生成一层筛选，约束度量值作用在哪些记录上。DAX和Excel公式最大的区别就在这里：Excel公式是固定范围的求和，DAX度量值是“范围随报表而动”的计算。
Total Sales := SUM( Sales[SalesAmount] )这段代码是书中一切度量的原型。SUM接收一个列，返回该列在筛选上下文中所有可见行的合计。当外部报表里的切片器选择2024年时，引擎会先缩小Sales表的可见行，再让SUM对缩小后的集合求和；当切片器选了两日年份时，引擎仍然按当前筛选后的集合计算，不会统计集合之外的数据。
参数说明：SUM只能接收单列，不能接收表达式；如果要做行级乘法再合计，就得用SUMX。理解这一点才能理解V2书中为什么反复强调“先问自己：我处于哪个上下文”。筛选上下文是引擎赋予度量值的环境，度量值本身只能顺应它，唯一能修改它的是CALCULATE。
提示：在计算列里写的表达式感知不到外部筛选上下文，这也是后续学习上下文转换时最先撞到的墙。
2.2 行上下文：迭代器为什么到处都是X
如果说筛选上下文是“站在外部看表”，行上下文就是“站在某一行看表”。DAX里只有两种地方会自动产生行上下文：计算列，以及以X结尾的迭代函数。SUMX、AVERAGEX、FILTER、ADDCOLUMNS，这些函数都要求进入每一行，逐行计算表达式，再按各自逻辑聚合。
Sales Amount := SUMX( Sales, Sales[Quantity] * Sales[UnitPrice] )这个度量值表达的是：遍历Sales表的每一行，在当前行分别取出数量和单价相乘，再把所有乘积加总。SUMX的两个参数中，第一个参数是要迭代的表，第二个参数是每一行上下文下要求值的表达式。参数说明：被迭代的表可以是物理表，也可以是一个返回表的表达式，比如FILTER的结果；第二参数中引用的列必须存在于当前迭代行可见的表中。
为什么V2书里大量使用迭代器而不是SUM？因为部分指标无法通过预聚合列直接求和，比如金额是两列相乘的结果。此时有两种选择：在导入阶段把金额提前算成一列，或者运行时用SUMX动态计算。选哪种取决于量和行的基数。书里的建议是：物理列可提前计算时优先提前计算；字段一旦涉及跨表相关性，只能依赖迭代器。
2.3 上下文转换：新手最容易翻车的地方
上下文转换是DAX引擎里最特殊的一环，也是V2书里浓墨重彩讲的一章。它描述的是这样一个机制：当你在一个行上下文中调用CALCULATE或CALCULATETABLE时，引擎会把当前的行上下文“压扁”成一层筛筛选上下文，再让表达式在新的筛选上下文中计算。
Is Large Order := IF( CALCULATE( SUM( Sales[SalesAmount] ) ) > 10000, "大额", "普通" )这段常见写法被用在同一张销售表的计算列中。IF先判断条件，条件内部对当前行执行CALCULATE；CALCULATE没有第二参数，但因为它会把当前行上下文转化为筛选上下文，SUM实际上只在“当前这一行”范围内求和，也就是这单金额本身。参数说明：阈值10000按业务口径调整即可。真正要理解的是CALCULATE括号里明明没写筛选条件，结果却发生了范围收敛，这就是上下文转换在起作用。
新手最容易犯的错误，是在行上下文里忘记CALCULATE，直接用SUM套列做逐行判断，结果SUM把整列都加在一起，每行返回同一个值。反过来，当计算列里写了太多CALCULATE时，上下文转换触发过于频繁，表达式会变得很慢。书里的建议是：计算列尽量少做，能放度量值就放度量值，因为度量值对引擎优化更友好。
注意：上下文转换是理解CALCULATE的关键，如果这段没想通就往下读，后面的时间智能函数全都会变成黑匣子。
3. 照着V2做练习：把核心度量值转成本地项目的三个高频场景
读DAX权威指南V2最容易犯的错，是把这本书当成“读完即会”的教材。实际上它更像一本手册，但手册必须配合实操才能内化。下面三个场景是业务报表里出现频率最高的写法，也是书中反复强调的必修单元：累计值、同比和加权指标。建议找一个自己熟悉的业务表，把列名替换成本地表，跟着写一遍。
3.1 先按书的目录搭一张DAX知识地图
V2目录很长，从头线性读到尾非常容易在中间章节失去动力。我一般会按下面的顺序跳读，先建立知识骨架，再回填细节。
| 阅读顺序 | 主题 | 核心函数 | 落地场景 |
|---|---|---|---|
| 1 | 公式语言基础 | CALCULATE、VAR | 理解度量值和计算列区别 |
| 2 | 上下文与转换 | CALCULATETABLE、ALL | 修正小计和占比错误 |
| 3 | 表函数 | FILTER、VALUES、DISTINCT | 做维度表和事实表关联 |
| 4 | 迭代器 | SUMX、AVERAGEX | 行级计算与加权指标 |
| 5 | 时间智能 | TOTALYTD、SAMEPERIODLASTYEAR | 同期、累计、移动平均 |
| 6 | 性能优化 | 变量缓存、迭代缩减 | 处理慢报表 |
这张顺序表的核心思路是：先能用，再求快。性能优化章节放在最后不是因为不重要，而是如果不理解上下文，性能章节里的每一条建议都很难落地。按这个顺序读完，再回到目录里补齐自己业务里还没碰过的函数。
3.2 从累计求和练起：CALCULATE + FILTER的正确姿势
以“年初至今累计销售额”为例。先不急着用时间智能函数，手工写一版 CALCULATE + FILTER，把筛选逻辑暴露出来。
Sales YTD := CALCULATE( SUM( Sales[SalesAmount] ), FILTER( ALL( 'Date' ), 'Date'[Year] = MAX( 'Date'[Year] ) && 'Date'[Date] <= MAX( 'Date'[Date] ) ) )这里的逻辑分两层。CALCULATE 第一参数做求和；第二参数传入FILTER返回的一张日期表。FILTER遍历ALL('Date')返回的全部分日期行，凡是满足当前筛选年份且日期不超过当前可见最大日期的行都被保留，其余被移除。ALL在这里的作用是清空外部筛选对年份的限制，让FILTER有完整日期表可遍历，而不是只遍历当前月份。如果不加ALL，筛选上下文已经把日期表限制在当月，FILTER遍历不全年，累计求和就会退化成当月求和。
MAX('Date'[Year])和MAX('Date'[Date])依赖外部筛选上下文取值：当报表按月份显示时，当前可见最大日期就是该月最后一天。参数说明：年份列必须是整数或文本且统一格式；日期列必须是日期类型，不能是文本日期，否则比较运算会出错。这一版写出来并跑通后，再换成书里推荐的标准写法：
Sales YTD := TOTALYTD( SUM( Sales[SalesAmount] ), 'Date'[Date] )TOTALYTD把上述FILTER逻辑封装进时间智能函数，第一参数是聚合表达式，第二参数是日期列。两种写法结果一致，后者更简洁且对引擎更友好。手工版本的意义在于帮助理解筛选条件如何从无到有被构造出来，理解之后就可以放手让标准函数接管。
3.3 从同比练时间智能：SAMEPERIODLASTYEAR与DATEADD的取舍
同比是管理层报表中必有的指标。DAX权威指南V2用大量篇幅讲时间智能函数，但这些函数都有一个前提：日期表必须连续且无重复，并且建立维度关系。如果日期表缺日期，同比结果会偏差。
Sales PY := CALCULATE( SUM( Sales[SalesAmount] ), SAMEPERIODLASTYEAR( 'Date'[Date] ) )SAMEPERIODLASTYEAR返回的是当前筛选上下文对应日期集合的上一年同期集合。假设当前筛选的是2024年1月，它返回2023年1月全部日期；假设筛选的是2024年全年，它返回2023年全年。参数必须传入日期列，不能传日期表，也不能传字符串。返回值是一张临时日期表，通常放在CALCULATE第二参数里使用。
与DATEADD的取舍在于周期类型。DATEADD(‘Date’[Date], -12, MONTH)和SAMEPERIODLASTYEAR在年同比上等价，但DATEADD支持季度、月度、周级的偏移，通用性更强。SAMEPERIODLASTYEAR写起来更短，语义也更明确。书里建议：只做年度同期时优先SAMEPERIODLASTYEAR；需要做季度环比、月度移动时用DATEADD。无论用哪个，都要在本地确认日期列从每年1月1日覆盖到12月31日，否则跨年计算会少一个月。
3.4 迭代器练习：用SUMX算加权平均
加权平均类指标是SUMX落地最常见的场景，比如按数量的加权单价、按库存的加权成本。公式本身很朴素：加权和除以总权重。
Avg Unit Price := DIVIDE( SUMX( Sales, Sales[Quantity] * Sales[UnitPrice] ), SUM( Sales[Quantity] ) )SUMX先把每行的数量和单价相乘，再逐行累加得到加权总金额；SUM直接对数量列求和得到销售总件数；DIVIDE把前者除以后者。参数说明：DIVIDE的第一参数是分子，第二参数是分母，第三参数是可选的除零结果，省略时返回BLANK。比起直接用斜杠除，DIVIDE在除数为零时不会报错，也不会让报表显示为无穷大，这是V2中明确推荐的原因之一。
做完这个练习后可以进一步追问自己：如果单价存在与商品维度表里，而不是销售事实表里，SUMX应该迭代哪张表？答案是仍然迭代销售表，通过关系用 RELATED或CALCULATE去取商品表的单价。这个追问能自然引出“扩展表”的概念，也是进入后续性能优化章节的伏笔。
4. DAX权威指南V2避坑：错误版本、术语错位与学了不会用的五个典型问题
任何经典技术书都会在读者群体中积累出一批“集体踩坑经验”。这些坑不是书里没写，而是书里的示例环境、文件格式和软件版本与读者的本地环境不一致导致的。下面五条，是按出现频率从高到低排下来的，每条都是实际可复现的案例。
4.1 现象：照书抄的代码在本地一直报“找不到列”
第一次照着PDF里的例子建度量值时，很容易出现列名不存在的报错。原因通常不是拼写问题，而是两个：一是示例数据库和自己的表结构列名不同，书里的Sales[SalesAmount]在本地叫Sales[金额]；二是扫描版PDF经过自动识别，代码里混入不可见字符，复制后DAX编辑器并不显示但执行时报语法错误。
解决方法是先建立“列名映射表”，把自己项目里每张表的字段和书中的示例字段逐一对应，别直接套用；在本地手动重打表达式，不要从PDF复制代码。如果表达式较长，建议每行只写一个参数，用快捷键格式化后再保存。
4.2 现象：PDF是不能搜索和选择文字的扫描版
用搜索引擎找到的PDF不一定都是文字版，很多扫描版每页是一张图片，Ctrl+F找不到关键词，代码无法选中复制，长时间阅读眼睛也容易疲劳。原因是原始版本经过纸质书扫描生成，没有保留文字层。
解决方法是优先确认PDF来源是否为“文字版”，可以试用PDF阅读器里的增强扫描或光学识别功能，对本地文件做一次识别后提取文字。识别后仍需要对“SUMX”“CALCULATE”这类公式字符做抽查，因为识别引擎对大小写混排的公式偶尔会识别错。更稳妥的做法是买正版电子书，官方电子版支持全文检索，示例文件也能一并下载，省下的时间远超那一点开销。
4.3 现象：同一段代码，书里返回的值和本地返回的值不同
书里的示例环境是特定软件版本下的引擎，而Power BI保持月度更新，部分函数的默认行为会在版本间调整。书里展示的示例结果针对的是固定的示例数据集，本地复制出来后，只要日期区间不同、事实表行数不同，结果就不可能完全一致。
解决方式是不要拿书里的数字当基准值，而是用书中的文字说明来验证计算逻辑。比如书里解释累计值的筛选条件如何生效，你就用本地的极简测试表手工算出预期值再对比，而不是复核书里的结果。DAX引擎的行为变化在V2书末版本说明里有标注，读这一节能提前避开不少版本坑。
4.4 现象：每个函数都认识，但是自己写的时候无从下手
书读完了，函数全画了线，结果拿到一个新需求还是不知道从哪起笔。原因在于DAX是体验型技能，筛选上下文和行上下文的交互需要真实的操作反馈来建立直觉，只看解释不足以形成迁移能力。
解决方法是每个章节抽出至少三个度量值，在Power BI里跑通并故意改错一次，观察报错或结果变化。把报错信息当作学习材料而不是干扰。比如故意去掉FILTER里的ALL，看累计值缩水成当月值，下一次看到类似症状时就能反向推断筛选上下文状态。
4.5 现象：网上找的电子版章节不全，示例文件也下载不了
电子版传播过程中经常出现缺页、少章节、图片分辨率被压缩的情况。示例数据库如果在书中正文没有附带，通常需要从官方产品相关的示例页单独下载，下载路径会随官网改版而失效。很多读者因为文件缺失，只能在书上看到一堆公式却无法跑通书中的练习数据。
解决方法是建议优先获取正版电子版，下载配套的示例数据库，按书中要求的路径导入Power BI。示例数据是理解书里场景的捷径，尤其是时间智能章节，没有结构化日期表几乎没法做练习。如果示例文件确实找不到，用一个连续日期表加工成日期维度表也可以，但要保存一份表结构说明，防止后面章节反复对不上。
注意：上面五条看似是工具问题，实质都是信息环境和版本环境造成的摩擦。书本身没错，错在读法太死。
5. 读完V2性能章节后的第一件事：用VAR重写你的旧度量值
DAX权威指南V2从第二版开始，几乎所有示例代码都使用了VAR结构。很多读者把VAR简单理解成“先定义变量，再返回结果”，却忽略了一个更重要的点：VAR是实现可读性和性能双提升的基础工具。读完性能章节后，第一件事不是学新函数，而是回头用VAR重写旧项目里所有超过三行的度量值。
5.1 为什么V2里大量使用VAR：不只为了代码可读性
VAR的关键规则是：定义变量时，引擎在首次被引用时计算一次，后续引用直接复用计算结果，不会重复求值。这意味着一个表达式里如果两次引用同一段子表达式，用VAR可以避免引擎计算两遍。
Sales YoY % := DIVIDE( SUM( Sales[SalesAmount] ) - CALCULATE( SUM( Sales[SalesAmount] ), SAMEPERIODLASTYEAR( 'Date'[Date] ) ), CALCULATE( SUM( Sales[SalesAmount] ), SAMEPERIODLASTYEAR( 'Date'[Date] ) ) )这版代码里，上年同期销售额被计算了两次：一次在分子里做减法，一次在分母里当除数。数据量小时感觉不到，数据量达到数百万行时，重复计算带来的时间开销就会显现。下面用VAR重写。
Sales YoY % := VAR SalesCurrent = SUM( Sales[SalesAmount] ) VAR SalesPrevious = CALCULATE( SUM( Sales[SalesAmount] ), SAMEPERIODLASTYEAR( 'Date'[Date] ) ) RETURN DIVIDE( SalesCurrent - SalesPrevious, SalesPrevious )重写后，SalesPrevious只计算一次，分子分母引用的是同一个缓存结果。参数说明：VAR定义后并不立即计算，而是在RETURN中第一次被提取时才求值，这一特性叫惰性求值，是V2性能章节中反复强调的引擎行为。新写度量值时，养成把公共计算提成VAR的习惯，代码行的数量看起来增加了，引擎的实际负担反而下降了。
5.2 用VAR把复杂的筛选条件拆成三步
当度量值里同时存在多个筛选维度时，VAR的第二个优势就体现出来了：可以把“筛选条件构造”和“聚合计算”拆开，让每个变量只承担一个职责，排查时按变量名逐段验证。
Complex Sales := VAR RegionFilter = "办公用品" VAR RecentDates = DATESINPERIOD( 'Date'[Date], MAX( 'Date'[Date] ), -30, DAY ) VAR BaseSales = CALCULATE( SUM( Sales[SalesAmount] ), RecentDates, Sales[Category] = RegionFilter, Sales[IsGift] = 0 ) RETURN BaseSales这段代码的业务含义是：计算最近30天内品类为办公用品且非赠品的销售额。三个VAR分别负责品类条件、日期窗口和聚合计算。参数说明：DATESINPERIOD的第三参数是偏移数，负数表示向前推；第四参数指定时间单位，DAY表示天，MONTH表示月。CALCULATE的筛选参数中，等值条件可以直接写“列=值”，引擎会把它转成内部筛选，比在FILTER里写整表迭代更高效。
这里有一个容易被忽略的细节：CALCULATE中的筛选参数同时引用了日期表变量和事实表条件列，引擎会自动处理表之间的扩展关系。如果BaseSales不在VAR里提出来而是直接放进RETURN，代码也能运行，但可读性会下降，排查时会分不清是哪一层筛选条件导致结果为空。
5.3 用VAR还能避免重复引用导致的性能浪费
很多人把VAR只当成“定义局部变量”，容易漏掉一个场景：在同一度量值中，同一个迭代器被多次使用时，如果迭代器的表的表达式写在VAR里，引擎可以共享这张表的内存结果。典型情况是“先筛选一张子表，再多次基于这张子表算不同指标”。
Sales KPIs := VAR FilteredSales = CALCULATETABLE( Sales, Sales[Channel] = "线上", Sales[IsGift] = 0 ) VAR TotalAmount = SUMX( FilteredSales, Sales[Quantity] * Sales[UnitPrice] ) VAR OrderCount = DISTINCTCOUNT( FilteredSales[OrderID] ) RETURN DIVIDE( TotalAmount, OrderCount )这个例子先构造一张“线上非赠品”的临时销售表，再基于同一张表计算加权金额和订单数两个指标。如果不使用VAR，两个指标各自重复构造一遍相同的筛选逻辑，引擎要跑两遍同样的计算。参数说明：SUMX对FilteredSales逐行迭代，DISTINCTCOUNT对同一个表的OrderID列去重计数，两张临时结果都来自同一个VAR实体。
注意：VAR能提升性能的前提是“同一度量值内重复引用”，跨度量值之间无法共享。如果多个度量值都在做同一份复杂筛选，优先考虑在模型层增加一个计算组或把筛选逻辑上卷到维度表，而不是在每个度量值里各写一遍。
6. 把书里的DAX查询思路做成自己的调试模板
读DAX权威指南V2过程中积累的写法，最终要沉淀成一套自己的调试模板。每次新建度量值，先用格式化的DAX查询验证定义，再放进报表页面观察交互筛选下的表现。这个习惯比多读十遍书都管用。
-- DAX调试模板.dax -- 场景：验证Sales YTD在2024年1月和2月的计算结果 DEFINE MEASURE Sales[Total Sales] = SUM( Sales[SalesAmount] ) MEASURE Sales[Sales YTD] = VAR CurrentDate = MAX( 'Date'[Date] ) RETURN CALCULATE( SUM( Sales[SalesAmount] ), 'Date'[Year] = YEAR( CurrentDate ), 'Date'[Date] <= CurrentDate ) EVALUATE SUMMARIZECOLUMNS( 'Date'[YearMonth], "Total Sales", Sales[Total Sales], "Sales YTD", Sales[Sales YTD] ) ORDER BY 'Date'[YearMonth]这段模板在DAX外部工具里可以直接运行，输出一张“年月、当月销售额、年初累计”的对照表。DEFINE段把度量值定义为本地实体，EVALUATE段最终返回结果表，SUMMARIZECOLUMNS按月份分组并计算两个度量值。调试时替换日期范围，就能快速判断筛选逻辑是否正确。
我自己的经验是每个度量值存一个独立的DAX片段文件，文件头写明场景、预期结果、实际结果三项。以前我拿到这本书先翻性能优化章节，结果连上下文转换都没吃透，性能建议一条都用不上，白白浪费了一个星期。后来老老实实回到上下文章节，每学一个新函数，就在测试表上跑一遍毛计算结果，再对照书里的文字解释。这个流程目前还在用，每次写新度量值都会比上一版少一次返工，希望帮到你。
本文还有配套的精品资源，点击获取
