这俩函数是 DAX 表函数里最容易被拿来一起说、又最容易被搞混的一对。我见过不少刚接触 Power BI 的人写 ADDCOLUMNS 想从表里挑几列结果把原表所有列都带出来了写 SELECTCOLUMNS 想追加计算列发现原列全没了。今天我直接从实际业务需求出发把这两个函数的定位、写法、坑点、性能差异一次性说透内容全部基于我在真实报表项目里的使用经验适合正在做数据建模、写度量值或者搭报表的 Power BI 开发人员参考。1. 别把它们当成同一类函数ADDCOLUMNS 是增列SELECTCOLUMNS 是投影1.1 一次报表需求逼我同时用上两个函数上个月接了一个销售分析需求业务方要的是客户销售排行榜在客户表基础上按客户算出销售额、订单数、环比上月增长率还要把客户等级分成 A/B/C 三档最后只保留排名前 20 的客户展示到报表里。这个需求看着简单但细想下来它其实包含了两类完全不同的表操作要给客户表追加计算列把每个客户的销售汇总结果变成新的一列这是 ADDCOLUMNS 的活追加完之后只需要保留客户姓名、销售额、订单数、等级这几个字段把原始表里和业务无关的列丢掉这是 SELECTCOLUMNS 的活。也就是说一个负责横向扩展列一个负责纵向挑选列。很多人在这个需求里翻车就是因为没分清增列和投影是两件事想用一个函数同时完成。1.2 两句话记住函数差异我用两句话来总结见面就能用ADDCOLUMNS(表, 新列名, 表达式)返回原表全部列 你追加的新列行数和原表一致。SELECTCOLUMNS(表, 列名, 表达式)返回只有你指定的那些列原表里没被指定的列全部不保留行数和原表一致。所以 ADDCOLUMNS 常用于给表扩充信息SELECTCOLUMNS 常用于从表里裁剪出需要的信息顺便重命名或重新计算。注意两个函数都不会改变行数它们不是汇总函数不会把多行压成一行也不会把一行展开成多行。1.3 共同前提行上下文的角色这两个函数还有一个共同底层机制它们都按行迭代。每处理一行DAX 引擎都会创建一个行上下文行上下文里你能直接访问当前行的列值。比如在 ADDCOLUMNS 里写Customer[CustomerName]拿到的就是当前这个客户的名称在 SELECTCOLUMNS 里写Sales[Quantity] * Sales[UnitPrice]就是对当前这行销售记录做行内计算。这个逐行执行的特性决定了两个函数都不能直接使用聚合函数做普通意义上的汇总。很多人在这里踩坑在 ADDCOLUMNS 里写SUM(Sales[SalesAmount])结果每一行返回的都是同一个总数。原因就是裸聚合函数响应的是筛选上下文不是行上下文当前行不会被自动当成筛选条件。后续第 4 节我会专门展开讲。理解到这一层你已经超过一半人了。接下来实操。2. ADDCOLUMNS 实战在现有表上长出新列2.1 语法拆解和最小可用示例ADDCOLUMNS 的完整语法ADDCOLUMNS( 表表达式, 新列名1, 表达式1, 新列名2, 表达式2, ... )几个关键点第一个参数是表表达式可以是一个物理表名也可以是一个返回表的函数比如FILTER、CALCULATETABLE、TOPN、另一个 ADDCOLUMNS。新列名必须用双引号包起来并且在同一层 ADDCOLUMNS 中不能重复。新列的列名不必和原表列名区分但如果重名后续引用时 DAX 可能优先匹配新列容易出歧义所以实际项目里我会习惯用有区分度的名字比如加前缀Total、Rank。表达式在每行的行上下文下计算。一个最小示例假如我要给客户表加一列客户所在城市全称其实就是拼接字符串EVALUATE ADDCOLUMNS( Customer, CityFullName, 城市- Customer[City] )结果表包含 Customer 表所有列外加 CityFullName。如果后续还要取数我只关心新列就得用 SELECTCOLUMNS 收窄。2.2 客户打标签的完整案例回到排行榜需求。首先我要给 Customer 表动态追加三列销售额、订单数、客户等级。DEFINE MEASURE Sales[Total Sales] SUM(Sales[SalesAmount]) EVALUATE VAR CustomerWithMetrics ADDCOLUMNS( Customer, Total Sales, [Total Sales], Order Count, CALCULATE( COUNTROWS(Sales) ), Customer Level, IF( [Total Sales] 100000, A级客户, IF( [Total Sales] 50000, B级客户, C级客户 ) ) ) RETURN CustomerWithMetrics这里有几个细节值得展开第一为什么Total Sales直接写度量值[Total Sales]因为 DAX 中引用一个已存在的度量值等价于把它包在 CALCULATE 里会自动发生上下文转换把当前行上下文转成筛选上下文。于是每个客户都能拿到属于自己的销售额汇总。如果你不用度量值而是直接写SUM(Sales[SalesAmount])结果就会是全体客户的总销售额重复出现在每一行——这就是上下文转换的威力。第二Order Count的计算。我用CALCULATE( COUNTROWS(Sales) )而不是裸的COUNTROWS(Sales)。裸的 COUNTROWS 只统计筛选上下文下的 Sales 行数和当前客户无关包一层 CALCULATE 后当前客户被作为筛选条件传递返回该客户的订单行数。第三Customer Level里引用了刚才算出列名。这里必须小心在同一个 ADDCOLUMNS 内部表达式之间不能直接引用前面定义的新列名。上面示例中我在 IF 里又写了一次[Total Sales]度量值它被再次求值一次。虽然语义正确但会多一次计算。更推荐的做法是先把结果算出来再用 VAR 逐层包装避免重复计算EVALUATE VAR CustomerWithMetrics ADDCOLUMNS( Customer, Total Sales, [Total Sales], Order Count, CALCULATE( COUNTROWS(Sales) ) ) VAR CustomerWithLevel ADDCOLUMNS( CustomerWithMetrics, Customer Level, IF( [Total Sales] 100000, A级客户, IF( [Total Sales] 50000, B级客户, C级客户 ) ) ) RETURN CustomerWithLevel表面上多写了一个 ADDCOLUMNS实际上每个客户的 [Total Sales] 只计算一次然后在下游被复用。这在数据量大时差异非常明显。2.3 为什么优先用 ADDCOLUMNS 而不是计算列在 Power BI 里同样可以给 Customer 表添加物理计算列表达式几乎一样Total Sales SUM(Sales[SalesAmount])。那为什么我推荐用 ADDCOLUMNS 做这种动态分析核心原因是计算列是持久化的。它会被存储在模型中随着每次数据刷新重算占用内存和磁盘空间。而且一旦计算列被用到表体积变大后续所有查询性能都会受影响。ADDCOLUMNS 则是在查询时临时构建虚拟表用完即走不落库。还有一层原因计算列是静态逻辑你写死了就不能根据筛选条件变化。比如报表里有个切片器控制只看华东区客户如果客户表里有一个是否计算的物理计算列它的值不会因为切片器选择而改变但 ADDCOLUMNS 是对当前筛选上下文下的 Customer 表做迭代天然会跟随报表筛选器变化。所以我的经验法则是除非这个列需要在数据模型层长期存在、被大量报表复用否则能写在 ADDCOLUMNS 里就不用计算列。当然计算列也有优势——它能被直接用作轴、图例、切片器而 ADDCOLUMNS 产生的虚拟列只能在查询内部使用不能直接拉到报表字段。这一点要结合具体使用场景取舍。3. SELECTCOLUMNS 实战压缩表宽、重塑结构3.1 语法拆解与基础投影SELECTCOLUMNS 的语法和 ADDCOLUMNS 长得几乎一样SELECTCOLUMNS( 表表达式, 列名1, 表达式1, 列名2, 表达式2, ... )但语义完全相反它不会保留原表的任何列只返回你列出的那些列。你可以把任意表达式塞进去哪怕这个表达式和原表的列完全无关因此它也可以用来创建一张从无到有的表。基础用法就是从一张宽表里挑出几列EVALUATE SELECTCOLUMNS( Sales, 订单号, Sales[OrderNo], 销售日期, Sales[OrderDate], 数量, Sales[Quantity], 销售额, Sales[SalesAmount] )结果只有 4 列行数和 Sales 一致。这个操作实质上就是关系代数里的投影。3.2 配合 RELATED 从多个表取列SELECTCOLUMNS 最常用的场景之一是把多张关联表中的列拼到一张表里生成一份拍平的明细。比如销售明细报表需要订单号、客户名、产品名、类别、销售额它们分布在三张表里。利用行上下文可以用 RELATED 顺着关系拿到另一端的列值EVALUATE SELECTCOLUMNS( Sales, 订单号, Sales[OrderNo], 销售日期, Sales[OrderDate], 客户名称, RELATED( Customer[CustomerName] ), 客户城市, RELATED( Customer[City] ), 产品名称, RELATED( Product[ProductName] ), 产品类别, RELATED( Product[Category] ), 销售额, Sales[Quantity] * Sales[UnitPrice] * (1 - Sales[Discount]) )这里注意RELATED 必须在行上下文中使用而 SELECTCOLUMNS 天然提供了行上下文所以成立。它和 ADDCOLUMNS 一样每行都能通过关系访问多对一端的列。我经常用这种方法做数据导出的清洗视图。比如财务要求导出一份字段顺序完全符合对方模板的 Excel直接在 DAX Studio 里 EVALUATE 这个 SELECTCOLUMNS导出结果一次成型不用在 Excel 里调整列顺序。3.3 用 SELECTCOLUMNS 构建 Top N 分析表Top N 是报表开发的高频需求。要拿到销售额前 20 的客户标准做法是先用 ADDCOLUMNS 计算每个客户的销售额然后用 TOPN 保留前 20 行最后用 SELECTCOLUMNS 投影出需要的列EVALUATE VAR CustomerWithSales ADDCOLUMNS( Customer, Total Sales, [Total Sales] ) VAR Top20Customers TOPN( 20, CustomerWithSales, [Total Sales] ) RETURN SELECTCOLUMNS( Top20Customers, 客户名称, Customer[CustomerName], 客户城市, Customer[City], 客户销售额, [Total Sales] )这个过程非常典型ADDCOLUMNS 负责扩展维度表TOPN 负责按度量排序裁剪行SELECTCOLUMNS 负责收窄列宽。三个函数各司其职组合起来就是一套完整的分析表构建流程。我自己写报表时经常把这个模式封装成度量值或命名表达式便于复用。比如报表页要展示 Top10 客户我就在页面级筛选器或视觉对象筛选器里用这个表。4. 十有八九翻车的地方上下文转换和列引用4.1 裸聚合为什么每次都一样这是所有 DAX 学习者绕不过去的坎。我先把最核心的真相讲清楚在一个迭代表函数里ADDCOLUMNS、SELECTCOLUMNS、FILTER、SUMX 等都算每一行都有行上下文。但是行上下文不会自动成为筛选条件它只告诉引擎当前在看哪一行。当你写SUM(Sales[SalesAmount])时这个 SUM 是在筛选上下文下计算的它根本不管行上下文所以每一行都会返回整个外部筛选下的总销售额。举个例子EVALUATE ADDCOLUMNS( Customer, 错误的总销售额, SUM(Sales[SalesAmount]) )结果每一行都显示 Sales 表的全部销售额完全没意义。解决办法是给聚合表达式套上 CALCULATE让 CALCULATE 完成上下文转换把行上下文中的当前行作为过滤器EVALUATE ADDCOLUMNS( Customer, 正确的总销售额, CALCULATE( SUM(Sales[SalesAmount]) ) )这里 CALCULATE 创建了一个新的筛选上下文把当前 ClientID 作为一个隐式筛选条件应用到 Sales 表上于是每个客户就拿到了自己的销售额。你可以把上下文转换理解成把当前行变成筛选项的操作。4.2 度量值引用为什么通常没问题有一种情况你不需要手工写 CALCULATE就是直接引用度量值。因为 DAX 中的度量值本身就是经过隐式 CALCULATE 包装的表达式当你写[Total Sales]时它等价于CALCULATE(SUM(Sales[SalesAmount]))。所以在 ADDCOLUMNS、SELECTCOLUMNS 内部引用度量值上下文转换自动发生EVALUATE ADDCOLUMNS( Customer, Total Sales, [Total Sales] )这也是我在 2.2 里优先使用度量值[Total Sales]的原因它让代码更简洁、不易出错。但是要留意如果一个度量值内部比较复杂比如引用了其他度量值多次转换可能导致性能下降。此时可以先把结果算成变量再传给表达式DEFINE MEASURE Sales[Order Count] COUNTROWS(Sales) EVALUATE ADDCOLUMNS( Customer, Order Count, [Order Count] )在大型模型中这个写法没问题但如果你担心性能可以手动计算EVALUATE ADDCOLUMNS( Customer, Order Count, CALCULATE( COUNTROWS(Sales) ) )第二种写法减少了度量值隐式转换的层数某些场景下会更快但可读性稍差。实际开发时我建议先用度量值把行业逻辑管理起来遇到性能瓶颈再做针对性优化。4.3 列名冲突与重复列的坑ADDCOLUMNS 和 SELECTCOLUMNS 产生的新列用的是你写在双引号里的名字。有两个坑要特别注意第一新列名重复会导致查询报错比如ADDCOLUMNS( Customer, CustomerName, Customer[CustomerName], CustomerName, Customer[City] )这种明显重复的写法DAX 直接拒了。但更隐蔽的是新列名和原表列重名导致后续引用歧义。比如SELECTCOLUMNS( ADDCOLUMNS( Customer, City, 临时城市- Customer[City] ), City, City )第二个City到底引用哪个是 Customer 原始列还是新列DAX 通常优先匹配新添加的列但这样写容易让阅读者困惑。我自己的规范是新列名一律带业务前缀或语义后缀避免和原列名撞车。第二SELECTCOLUMNS 投影列的顺序。SELECTCOLUMNS 返回表的列顺序完全由你书写参数时的顺序决定。这在导出 Excel 时很有用但如果是后续传给其他函数处理列顺序变化可能导致原有表达式失效建议通过列名引用别依赖位置。5. 动手前先想清楚性能取舍与调试方法5.1 物化表与列宽的成本从性能角度讲ADDCOLUMNS 和 SELECTCOLUMNS 都是物化函数它们返回的新表会被 DAX 引擎实际存储到内存里供后续计算使用。这就带来两个成本行数成本迭代多少行就要多少计算量。在稀疏列覆盖的巨大事实表上盲目 ADDCOLUMNS 可能让查询卡死。列宽成本ADDCOLUMNS 会保留原表所有列如果原表有 50 列你只新增 1 列最终物化的表就有 51 列虽然你后面可能只用其中 2 列但前 50 列已经占用了内存和计算时间。所以我的性能原则是先用 SELECTCOLUMNS 把表收窄再做计算。让 ADDCOLUMNS 作用在尽可能窄的表上。ADDCOLUMNS 内避免过多嵌套物化。如果连续 3 层 ADDCOLUMNS每一层都会生成一张新表内存压力成倍放大。能用变量传递中间表就多用变量避免同一张虚拟表被重复构建多次。不要用 ADDCOLUMNS 给超大事实表逐行加一堆无谓的字符串列。行上下文迭代成本不低能提前在 SQL 或 Power Query 里完成的转换就在数据源侧完成。5.2 实测量化在 DAX Studio 里看聚合引擎判断一段 ADDCOLUMNS / SELECTCOLUMNS 是否慢不要凭感觉在 DAX Studio 里跑一次就知道。重点看两点存储引擎查询的次数以及公式引擎的耗时。比如一个报表视觉对象最终执行了 200 次存储引擎查询其中 150 次都来自同一个复杂度量值内部的 ADDCOLUMNS 嵌套那么你就应该考虑把中间表结果缓存到变量里或者精简表结构。经验值最终视觉对象的数据粒度应该就是视觉对象需要的粒度。如果只是展示 Top10 客户那查询内部就该先 TOPN 再返回 10 行不要在中间环节物化整个 Customer 表再加一堆列最后才 TOPN。5.3 三个实用调试技巧调试这两个函数时我有三个惯用技巧技巧一在 DAX Studio 里用 EVALUATE 直接看结果。任何表函数都可以通过 EVALUATE 单独运行立刻看到返回表的内容、列名和类型。写报表度量值出错时我第一件事就是把它里面的 ADDCOLUMNS / SELECTCOLUMNS 部分抽出来放到 DAX Studio 里 EVALUATE确认中间结果长什么样。技巧二用一个标志列拆解上下文问题。当 ADDCOLUMNS 里的聚合结果异常时我会临时加一列输出当前行的标识信息再对比聚合结果EVALUATE ADDCOLUMNS( Customer, 当前客户ID, Customer[CustomerID], 当前销售额, [Total Sales] )如果当前客户ID各不相同但当前销售额全部一样那就是上下文转换没生效八成是没用 CALCULATE 或度量值。技巧三用 COUNTROWS 快速验证行数。确认表函数没有意外改变行数EVALUATE VAR T ADDCOLUMNS( Customer, Total Sales, [Total Sales] ) RETURN ROW( 客户行数, COUNTROWS(Customer), 新表行数, COUNTROWS(T) )如果两者不一致说明表达式有问题不要直接跳到下一步。6. 从会用到活用和 TOPN、GENERATESERIES 的组合6.1 TOPN ADDCOLUMNS SELECTCOLUMNS 的黄金组合这三个函数组合是我在大客户分析类报表中最常用的套路前面已经展示过一遍。我再补充一个带排序和序列号的版本EVALUATE VAR CustomerWithSales ADDCOLUMNS( Customer, Total Sales, [Total Sales] ) VAR RankedCustomers ADDCOLUMNS( CustomerWithSales, Rank, RANKX( CustomerWithSales, [Total Sales], , DESC, Dense ) ) VAR Top20 FILTER( RankedCustomers, [Rank] 20 ) RETURN SELECTCOLUMNS( Top20, 排名, [Rank], 客户名称, Customer[CustomerName], 客户销售额, [Total Sales] )这里把 RANKX 的结果也放在 ADDCOLUMNS 里生成再用 FILTER 按排名过滤。注意 RANKX 的表达式求值上下文和外部 ADDCOLUMNS 的行上下文是两个不同的上下文调试时务必分清。这段代码直接丢到报表里作为表度量值可以配合切片器做动态 Top N。6.2 GENERATESERIES ADDCOLUMNS 生成参数表有时候你需要一张数字参数表比如让用户选最近 N 天这可以用 GENERATESERIES 生成连续整数再用 ADDCOLUMNS 为每个数字添加业务含义EVALUATE ADDCOLUMNS( GENERATESERIES(1, 30, 1), 天数说明, 近 [Value] 天 )这种参数表可以配合切片器使用让用户在 1 到 30 天之间选择。SELECTCOLUMNS 同样可以用于重新命名 GENERATESERIES 返回的默认列名Value让表更可读EVALUATE SELECTCOLUMNS( GENERATESERIES(1, 30, 1), 天数, [Value], 天数说明, 近 [Value] 天 )不过要注意GENERATESERIES 默认返回列名是 Value在 SELECTCOLUMNS 里引用它要写成[Value]这个语法和表列引用不同因为它是无表前缀的列引用。6.3 一个比较综合的报表案例最后放一个更接近真实业务需求的结构它把本节所有内容串起来了。假设我想做一个各产品类别的销售额贡献明细要求包含产品类别、所属产品数、总销售额、销售额排名最终只显示前 5 类EVALUATE VAR CategorySummary ADDCOLUMNS( VALUES( Product[Category] ), 产品数, CALCULATE( COUNTROWS(Product) ), 销售额, [Total Sales], 排名, RANKX( ALL( Product[Category] ), [Total Sales] ) ) RETURN FILTER( SELECTCOLUMNS( CategorySummary, 产品类别, Product[Category], 产品数, [产品数], 销售额, [销售额], 排名, [排名] ), [排名] 5 )注意这里用了ALL( Product[Category] )来忽略外部切片器对 Category 的筛选保证排名是在所有类别上计算的而不是只在当前筛选下排名。这个细节很容易被忽略但在商业报表中影响很大。从上面的例子可以看到ADDCOLUMNS 和 SELECTCOLUMNS 不只是两个孤立的函数它们是 DAX 表操作链条里的核心环节。ADDCOLUMNS 负责把行上下文中的计算结果变成新列SELECTCOLUMNS 负责把表裁剪成最合适的形状两相结合才能构建出高效、可读、易维护的分析逻辑。根据我自己的使用经验最后再补充一条非常实际的建议写这两个函数前先在纸上把输入表长什么样、输出表要哪些列、行数变不变这三个问题回答清楚。只要这个问题理清了ADDCOLUMNS 和 SELECTCOLUMNS 的用法就不会出错。特别是行数不变的特性经常被忽略但这恰恰是理解它们和 SUMMARIZE、GROUPBY 这类分组函数的关键分水岭——分组函数会压缩行数而这两个函数保持行数原样只是把列的方向做加减法。抓住了这个本质后续你写复杂的 DAX 表达式会顺畅很多。