Power BI 性能优化：DAX、模型和查询

需要 15 秒加载的 Power BI 报表是用户停止使用的报表。性能不是技术细节——它是 BI 采用和放弃之间的区别。报告加载时间的每一秒都会显着降低用户参与度。研究一致表明，交互式仪表板（加载时间低于 3 秒）接收的视图比慢速仪表板（加载时间超过 10 秒）多 4-5 倍，并且遇到持续缓慢的用户会在 30 天内恢复到手动流程。

好消息是 Power BI 性能问题几乎总是可以解决的。根据我们优化数百个 Power BI 环境的经验，90% 的性能问题可追溯到五个根本原因之一：效率低下的 DAX 度量、数据模型过大、关系设计不佳、DirectQuery 使用不当或工作负载容量不足。本指南提供了诊断和解决每个问题的系统方法。

如果您的 Power BI 环境遇到团队无法内部解决的性能问题，我们的 Power BI 性能优化服务 可以提供实际分析和修复。

要点

• Power BI Desktop 中的性能分析器可识别哪些视觉效果和查询速度较慢 --- 在优化之前始终从此处开始
• DAX Studio 揭示了慢速查询是否是存储引擎（数据扫描）或公式引擎（计算）中的瓶颈 --- 修复方法差异很大
• 最常见的 DAX 性能错误是不必要的 CALCULATE 嵌套、在聚合器足够的情况下使用迭代器以及具体化大型中间表
• 模型大小直接影响性能：删除未使用的列、减少基数和优化数据类型可以将模型缩小 40-70%
• 聚合表通过预先计算汇总数据，为大型数据集提供 10-100 倍的查询性能改进
• DirectQuery 比交互式报告的导入模式慢 10-100 倍 --- 仅当数据新鲜度要求确实需要时才使用它
• 使用记录的指标进行基准测试之前/之后对于证明优化影响和防止回归至关重要

---

诊断工具和方法

性能分析器

性能分析器是 Power BI Desktop 的内置诊断工具。它记录报告页面上每个视觉对象生成的每个查询的执行时间，将时间分为三个部分：

如何使用性能分析器：

1. 在 Power BI Desktop 中打开报表。
2. 转到视图 > 性能分析器。
3. 单击“开始录制”。
4. 与报表交互（更改过滤器、导航页面、应用切片器）。
5. 单击“停止”。
6. 查看按总持续时间排序的结果。

解释结果：

• 如果 DAX 查询时间占主导地位，则问题出在您的度量或模型中。使用 DAX Studio 进行更深入的分析。
• 如果视觉显示时间占主导地位，则问题出在视觉配置中（数据点过多、条件格式复杂或性能不佳的自定义视觉）。
• 如果“其他”时间占主导地位，则问题出在基础设施上（DirectQuery 的网络延迟、网关瓶颈或容量限制）。

大多数人跳过的关键步骤： 从性能分析器复制 DAX 查询（右键单击 >“复制查询”）并将其粘贴到 DAX Studio 中。性能分析器会告诉您哪个视觉效果较慢。 DAX Studio 告诉你原因。

DAX 工作室

DAX Studio 是一款免费的开源工具，可为 Power BI 底层的 Analysis Services 引擎提供深度诊断功能。它是任何 Power BI 性能工程师工具包中最重要的工具。

DAX Studio 的关键功能：

服务器计时： 显示存储引擎 (SE) 和公式引擎 (FE) 查询时间之间的细分。

• 存储引擎 (SE) 查询是针对列式存储（VertiPaq 引擎）执行的数据扫描。它们高度并行且速度快。 SE 查询在跟踪中显示为 xmSQL 语句。
• 公式引擎 (FE) 操作 是对 SE 查询结果执行的单线程计算。 FE 操作是大多数缓慢的 DAX 衡量指标的主要瓶颈。

优化目标是将尽可能多的工作推入存储引擎并最小化公式引擎操作。

查询计划： DAX Studio 可以显示逻辑和物理查询计划，准确显示引擎如何处理您的度量。对于高级用户来说，查询计划揭示了仅在计时数据中不可见的优化机会。

VertiPaq 分析器： 扫描整个数据模型并报告每个表中每一列的列大小、基数、编码类型和字典大小。这是您识别导致模型膨胀的过大列和表的方法。

系统优化方法

1. 基线： 使用性能分析器记录每个页面的加载时间。记录模型大小（文件 > 信息 > 减小文件大小 > 分析）。如果在 Premium/Fabric 上，则记录容量指标。

2. 识别： 按总持续时间对性能分析器结果进行排序。重点关注前 5 个最慢的视觉效果 --- 这些视觉效果在优化后会产生最大的影响。

3. 诊断： 将每个慢查询复制到 DAX Studio。分析 SE 与 FE 时间。识别导致 FE 瓶颈的特定 DAX 模式。

4. 优化： 应用有针对性的修复（下面详细介绍）。单独测试每个更改以衡量其影响。

5. 验证： 重新运行性能分析器并与基线进行比较。记录每个优化的改进。

6. 监控： 设置持续的性能监控（容量指标、用户报告的问题、定期性能分析器检查）以防止回归。

---

缓慢的 DAX 模式和修复

模式 1：不必要的 CALCULATE 嵌套

问题：

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

嵌套 CALCULATE 语句不会增加功能 --- 它们会增加混乱，有时还会增加性能开销。每个 CALCULATE 都会创建一个新的过滤器上下文，嵌套它们可能会产生意外的结果并强制公式引擎执行冗余的上下文转换。

修复：

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

将过滤器参数合并到单个 CALCULATE 中。同时应用多个过滤器参数（交集）。这会通过更清晰的执行产生相同的结果。

模式 2：使用 ALL 进行筛选而不是直接列筛选

问题：

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Products), ...) 强制引擎具体化公式引擎中的整个 Products 表，然后迭代每一行以应用过滤器。对于具有数百万行的表来说，这是非常慢的。

修复：

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

CALCULATE 中的直接列过滤器在存储引擎中解析，速度快了几个数量级。仅当您需要应用无法表示为简单列比较的复杂条件（例如，对度量值进行过滤或涉及多列的条件）时，才使用 FILTER。

经验法则： 如果您的 FILTER 条件通过简单比较引用单个列，请将其替换为直接 CALCULATE 筛选参数。为真正复杂的条件保留 FILTER。

模式 3：聚合器足以满足需求的迭代器

问题：

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX 迭代销售表的每一行，计算公式引擎中每一行的表达式。对于具有 1000 万行的 Sales 表，这意味着 1000 万次 FE 操作。

修复：

如果计算是两列的简单乘法，则将其预先计算为计算列：

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM 在存储引擎中运行，该引擎以高度优化的批次处理列式数据。计算列增加了模型大小，但显着减少了查询时间。

何时保留 SUMX： 当您需要行级条件逻辑（例如 SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))）或迭代小表（具有数千行而不是数百万行的维度表）时，请使用 SUMX。

模式 4：大型中间表

问题：

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE 在公式引擎中创建一个中间表。如果类别和月份的组合产生 10,000 行，并且 [复杂计算] 为每行触发额外的 SE 查询，则结果是 10,000 多个查询 --- 一种称为“SE 查询风暴”的灾难性性能模式。

修复：

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

通过在 ADDCOLUMNS 中具体化小计（有效地使用上下文转换），对 @SubTotal 的后续引用不会触发额外的 SE 查询。变量 (VAR) 还确保表仅计算一次，即使多次引用也是如此。

模式 5：行级安全性能影响

问题：

具有复杂 DAX 表达式的 RLS 对每个查询进行计算，增加了跨视觉效果的开销。写得不好的 RLS 规则可能会使报告加载时间增加一倍或三倍。

常见的 RLS 性能杀手：

• RLS 过滤器中的 LOOKUPVALUE（强制每行进行 FE 评估）
• 大表上的 CONTAINS 或 IN 运算符
• RLS 规则引用度量而不是简单的列过滤器
• 具有跨过滤器方向问题的多表 RLS

修复：

• 使用简单的列比较：[TenantId] = USERNAME() 或 [Region] IN VALUES(SecurityTable[Region])
• 在具有直接关系的专用维度表中预先计算安全映射
• 避免 RLS 规则中的措施 --- 仅使用列级过滤器
• 通过比较启用和不启用 RLS 的查询时间，使用 DAX Studio 测试 RLS 性能

---

模型尺寸缩小

为什么模型尺寸很重要

Power BI 导入模式以高度压缩的列格式存储数据（VertiPaq 引擎）。模型大小直接影响：

• **内存消耗：**整个模型必须适合内存。在 Premium/Fabric 上，较大的模型会消耗更多容量，并可能会触发内存压力限制。
• 刷新持续时间： 较大的模型需要更长的刷新时间，因为必须处理、压缩和加载更多数据。
• 查询性能： 较大的模型会产生较大的扫描，这会增加查询时间，即使对于优化良好的 DAX 也是如此。
• 文件大小： 具有大模型的 PBIX 文件的保存、发布和下载速度很慢。

识别模型大小贡献者

使用 DAX Studio 的 VertiPaq 分析器（高级 > 查看指标）来识别最大的表和列：

优化技术

删除未使用的列：

影响最大的单一优化。模型中的每一列都会消耗内存，无论是否使用。审核您的模型并删除视觉、度量、关系或 RLS 规则中未引用的任何列。

典型影响：模型尺寸缩小 20-40%。

减少文本列基数：

具有许多唯一值（描述、地址、注释）的文本列压缩效果很差。如果该列仅用于显示（而不是过滤或分组），请考虑将其移至仅包含详细信息的表或截断长值。

对于分组/过滤中使用的列，请考虑分桶：不要使用 50,000 个唯一的产品名称，而是将其分组为 500 个产品类别，并使用单独的查找表来查找各个产品的详细信息。

优化数据类型：

• 当值为整数时，使用整数而不是小数（每列节省 50%）
• 当不需要时间时使用日期而不是日期时间（减少基数）
• 避免将数值存储为文本（文本压缩比数字差得多）
• 使用布尔值代替文本来表示是/否或真/假列

典型影响：模型尺寸缩小 10-20%。

分割大表：

包含 1 亿行的事实表可以分为活动数据（当年，每次刷新时加载）和历史数据（往年，加载频率较低或存储为聚合）。这会减少模型大小和刷新持续时间。

聚合表（下面详细介绍）：

对于大型事实表，聚合表通过以常用查询粒度预先计算汇总数据来提供最大的性能改进。

---

聚合表

什么是聚合表

聚合表是 Power BI 查询的预先计算的汇总表，而不是扫描完整的详细信息表。当用户查看按区域显示每月收入的图表时，Power BI 查询聚合表（可能有 120 行：10 个区域 x 12 个月）而不是详细表（可能有 5000 万个事务行）。

聚合表的强大之处在于它们对报表使用者是透明的。用户与相同的视觉效果和度量进行交互。当查询粒度匹配时，Power BI 会自动将查询路由到聚合表，并深入到详细表以进行向下钻取或详细级别查询。

设计聚合表

第 1 步：确定聚合粒度。

分析您的报告以确定最常见的查询粒度。对于销售仪表板：

• 月份+地区+产品类别级别的大多数执行视觉查询
• 周+商店+产品级别的经理视觉查询
• 单个事务级别的明细表查询

以最常查询的粒度设计一两个聚合表。

步骤 2：创建聚合表。

在 Power Query 中，创建一个新表，以聚合粒度对事实表进行分组：

步骤 3：配置聚合映射。

在 Power BI Desktop 中，选择聚合表，转到“属性”>“管理聚合”，然后将每个聚合列映射到其相应的详细信息表列和函数：

第 4 步：隐藏聚合表。

用户不应直接与聚合表交互。从报告视图中隐藏它。 Power BI 自动且透明地使用它。

聚合性能影响

这些改进在报告页面上得到了体现。包含 10 个视觉对象的页面（每个视觉对象都查询聚合表而不是详细信息表）可能会在 1 秒内加载，而不是 30 秒。

聚合表维护

• 按照与明细表相同的时间表刷新聚合表以保持一致性
• 使用 DAX Studio 监控聚合命中率（跟踪事件显示查询是否命中聚合或失败）
• 当您确定其他常见查询模式时添加新的聚合表
• 删除命中率低于 50% 的聚合表（它们消耗空间但没有足够的好处）

---

DirectQuery 优化

何时需要 DirectQuery

DirectQuery 实时查询源数据库，而不是将数据导入 Power BI 的内存引擎。在以下情况下有必要：

• 数据新鲜度要求要求亚分钟延迟（股票交易、物联网监控、欺诈检测）
• 数据集超出了 Power BI 的模型大小限制（Premium P1 上为 10GB，P2 上为 25GB 等）
• 合规性或安全性要求数据永远不会离开源系统
• 源数据库已经拥有广泛的物化视图和聚合基础设施

对于所有其他场景，强烈首选导入模式。导入模式的交互式查询速度提高了 10-100 倍，并提供了更好的用户体验。

DirectQuery 性能策略

减少每页的视觉效果数量。

DirectQuery 模式下的每个视觉对象都会生成对源数据库的单独查询。具有 20 个视觉效果的页面在加载页面时会生成 20 个并发查询，并在筛选器更改时生成额外的查询。将 DirectQuery 页面限制为最多 8-10 个视觉对象。

优化源数据库。

Power BI 将 SQL 查询（或非 SQL 源的本机查询）发送到源。源数据库的性能直接决定报表的性能。确保：

• 过滤器、关系和度量中使用的所有列都存在索引
• 查询表上的统计信息是最新的
• 数据库服务器有足够的CPU和内存来处理并发分析查询和操作工作负载
• 考虑为常见查询模式创建物化视图或索引视图

启用查询减少选项。

在 Power BI Desktop > 选项 > 查询缩减中，启用：

• “通过不发送交叉突出显示查询来减少发送的查询数量”：防止视觉对象之间的交叉过滤生成额外的查询
• “为每个切片器添加应用按钮”：用户在执行查询之前调整多个切片器，减少总查询量
• “向过滤器窗格添加应用按钮”：过滤器窗格的原理相同

策略性地使用双存储模式。

表可以设置为“双”模式，该模式既以导入模式存储数据（用于快速本地查询），又维护 DirectQuery 连接（用于与 DirectQuery 表的关系）。将维度表（产品、客户、日期）设置为双模式，同时在 DirectQuery 中保留大型事实表。这极大地提高了过滤器和切片器的性能，而不会牺牲事实表上的数据新鲜度。

实施查询缓存。

在 Power BI 服务数据集设置中启用“查询缓存”。这会在可配置的时间内缓存查询结果，为相同的查询提供缓存结果。查询缓存对于许多用户使用相同过滤器查看的仪表板（例如，显示公司范围指标的执行仪表板）特别有效。

---

容量性能监控

关键容量指标

对于使用 Premium 或 Fabric 容量的组织来说，基础设施性能与报表设计同样重要。容量限制甚至可能使优化良好的报告表现不佳。

要监控的指标：

Microsoft Fabric 容量指标应用程序

Microsoft 在 Power BI 服务中提供了专用的容量监控应用程序。从 AppSource 安装它并将其连接到您的容量。它提供：

• 实时和历史 CPU 利用率，并按工作负载类型进行细分
• 交互式节流分析显示哪些操作触发了节流
• 具有驱逐历史的数据集的内存消耗
• 刷新性能趋势
• 查询性能百分位数

在优化阶段每周检查一次此应用程序，在稳定状态期间每月检查一次。

容量调整

容量配置不足会导致流量限制和用户体验不佳。过度配置的容量会浪费金钱。正确调整规模需要了解您的工作负载模式：

• 高峰使用时间： 大多数组织在工作时间的负载比夜间高 2-3 倍。如果您根据高峰调整尺寸并拥有 Fabric F SKU，请考虑暂停过夜或在非工作时间缩小规模。
• **刷新与交互式冲突：**数据刷新和交互式查询竞争相同的容量资源。在高峰互动时间之外安排大量刷新。如果不可能，请考虑为刷新和交互式工作负载提供单独的容量。
• 增长预测： 规划 6-12 个月的增长。模型大小、用户数量和查询复杂性都会随着时间的推移而增加。在容量调整中留出 30-50% 的空间。

---

基准测试之前/之后

为什么基准测试很重要

没有测量的优化只是猜测。基准测试之前/之后证明改变可以提高性能，量化利益相关者的改进，并创建用于检测未来回归的基线。

基准测试方法

第 1 步：定义指标。

步骤 2：记录基线。

在进行任何更改之前，记录所有指标。运行性能分析器 10 次以考虑缓存预热和变化。记录每个指标的中位数 (P50) 和第 95 个百分位 (P95)。

第 3 步：逐步实施变更。

一次进行一项优化，并在每次更改后重新测量。这可以确定哪些优化产生了最大的影响，并防止用其他地方的改进来掩盖回归。

第 4 步：记录优化后指标。

完成所有优化后，使用相同的方法记录相同的指标。将结果呈现在比较表中：

第 5 步：安排持续监控。

随着数据的增长、新度量的添加以及新视觉效果的创建，性能会随着时间的推移而下降。使用相同的方法安排季度绩效评估，以便及早发现回归现象。

对于需要通过记录前后指标进行系统性能优化的组织，ECOSIRE 提供全面的 Power BI 性能服务，包括 DAX Studio 分析、模型优化和容量调整。

---

高级优化技术

计算组

计算组用可重用的计算逻辑替换重复的测量变量。计算组动态应用这些转换，而不是为每个基本度量创建 MTD、QTD、YTD、上一年和同比增长的单独度量。

性能优势： 模型中的度量越少意味着元数据占用空间越小，模型加载速度越快。更重要的是，计算组鼓励更简单的基本度量，这往往比复杂的一体化度量表现更好。

复合模型

复合模型将导入模式和 DirectQuery 表组合在一个模型中。对于维度表和频繁查询的事实表使用导入模式，对于导入更改过于频繁的非常大的表使用 DirectQuery。

性能优势： 维度查找和筛选操作以导入速度（微秒）运行，而事实表查询以 DirectQuery 速度（数百毫秒到秒）运行。最终结果明显优于纯 DirectQuery。

增量刷新

增量刷新在刷新期间仅加载新的和更改的数据，而不是重新加载整个数据集。对于每天只有 10 万行变化的 1 亿行表，增量刷新可减少 99% 的刷新时间。

配置： 在 Power Query 中定义 RangeStart 和 RangeEnd 参数。配置增量刷新策略，指定刷新多少天/月的数据以及保留多少历史数据。 Power BI 自动对数据集进行分区并仅刷新活动分区。

性能优势： 刷新持续时间和刷新期间的容量消耗大幅减少。还可以使用 Fabric 容量上的 DirectQuery 分区进行实时刷新。

查询折叠

查询折叠将 Power Query 转换推回源数据库，将其作为本机 SQL 执行，而不是在 Power Query 引擎中执行。折叠查询运行速度要快得多，因为数据库引擎会在本机优化和执行它们。

如何验证： 右键单击​​ Power Query 编辑器中的任意步骤，然后检查“查看本机查询”是否可用。如果是，则查询将折叠到该步骤。如果呈灰色，则表示折叠在上一步中中断。

常见的折叠断路器： 具有 M 表达式的自定义列、合并来自不同源的表、某些转换（旋转、复杂类型转换）。当折叠中断时，所有后续转换都在 Power Query 引擎中执行，这对于大型数据集来说速度明显较慢。

---

常见问题解答

Power BI 报表加载时间的最佳目标是什么？

常用仪表板的目标时间在 3 秒以内，详细分析报告的目标时间在 5 秒以内。这些目标符合用户对 Web 应用程序的期望，并保持高参与度。应优先优化持续超过 10 秒的报告。从用户的角度衡量加载时间（包括网络和渲染），而不仅仅是 DAX 查询时间。每个视觉效果的性能分析器 DAX 查询时间加上视觉呈现时间总计应低于 2 秒，以实现 8-10 个视觉效果的 3 秒页面加载。

我是否应该始终选择导入模式而不是 DirectQuery？

对于业务用户使用的交互式报告，是的——导入模式几乎总是更好的选择。导入模式的查询速度提高了 10-100 倍，在查看报表时不依赖于源数据库性能，并支持全系列 DAX 功能和 AI 功能。仅当您确实需要亚分钟级的数据新鲜度、数据集超出导入大小限制或合规性要求数据保留在源系统中时，才使用 DirectQuery。将复合模型视为中间立场：导入维度和经常查询的事实，DirectQuery 仅导入真正需要实时新鲜度的表。

我应该多久对 Power BI 报表运行一次性能审核？

每季度对生产报告进行一次全面的绩效审计。在审核之间，每周监控容量指标并及时调查用户报告的任何缓慢情况。应立即触发审核的重大事件包括：数据量显着增长（增长超过 25%）、添加新的报告页面或复杂的 DAX 度量、用户并发度变化（启动后用户增长）以及容量变化（升级、降级或迁移）。

我可以在不更改报表的情况下优化 Power BI 性能吗？

是的，在某种程度上。基础设施级优化包括：升级容量SKU、在服务设置中启用查询缓存、在高峰时段之外安排大量刷新、配置网关集群以获得更好的吞吐量以及优化源数据库（索引、统计信息、物化视图）。这些更改在不影响报告文件的情况下提高了性能。然而，最有影响力的优化通常涉及报表级别的更改：DAX 度量重写、模型大小减小、聚合表和视觉计数减少。基础设施优化解决容量限制；报告优化解决效率问题。

是什么导致 Power BI 报告随着时间的推移变得更慢？

五个常见原因： (1) 数据量增长——随着表从 100 万行增长到 1000 万行，相同的查询需要更长的时间。 (2)措施积累——在没有优化现有措施的情况下添加新措施，措施之间的相互作用会造成复合复杂性。 (3) 视觉蔓延——用户在每页添加更多视觉效果，每个视觉效果都会生成额外的查询。 (4) 模型膨胀——添加新的列和表而不删除未使用的列和表。 (5)并发用户增长——更多的用户竞争相同的容量资源。通过季度绩效审计、限制视觉计数和衡量复杂性的治理策略以及主动容量监控来解决这些问题。