使用表级别存储优化 DirectQuery 模型
DirectQuery 是将数据导入 Power BI Desktop 的一种方法。 DirectQuery 方法是直接连接到 Power BI Desktop 内部源存储库的数据。 这是将数据导入 Power BI Desktop 的替代方法。
使用 DirectQuery 方法时，整体用户体验在很大程度上取决于底层数据源的性能。 查询响应时间缓慢会导致用户体验不佳，极端情况下还可能导致查询超时。此外，同时打开报表的用户数量也会影响数据源承受的负载。 例如，如果报表中包含 20 个视觉对象，并且有 10 个用户在使用报表，则数据源上会存在 200 个或更多查询，因为每个视觉对象都将发出一个或多个查询。
遗憾的是，Power BI 模型的性能不仅会受到底层数据源性能的影响，还会受到其他不可控因素的影响，例如：
网络延迟：网络速度越快，返回数据的速度就越快。
数据源服务器的性能以及该服务器上的其他工作负载数量。 例如，数百人出于不同原因使用同一服务器时，会对服务器刷新造成很大影响。
因此，使用 DirectQuery 会对模型性能的质量带来一定的风险。 要在此情况下优化性能，必须能够控制（或访问）源数据库。
有关详细信息，请参阅 Power BI Desktop 中的 DirectQuery 模型指导。
使用 DirectQuery 的影响
最佳做法是将数据导入 Power BI Desktop，但您的组织可能出于以下某种原因（或者说 DirectQuery 的优点）而需要使用 DirectQuery 数据连接模式：
它适用于数据频繁更改并需要准实时报告的情况。
它无需预先聚合即可处理大型数据。
它应用数据主权限制来符合法律要求。
它可以与包含 SAP Business Warehouse (BW) 等度量值的多维数据源一起使用。
如果您的组织需要使用 DirectQuery，您应该清楚地了解其在 Power BI Desktop 中的行为并注意其局限性。 这样，您才能占据有利位置，采取措施尽可能优化 DirectQuery 模型。
DirectQuery 连接的行为
当您使用 DirectQuery 连接 Power BI Desktop 中的数据时，该连接的行为方式如下：
当首次使用 Power BI Desktop 中的获取数据功能时，您将需要选择源。 如果连接到关系源，则可以选择一组表，每个表会定义一个以逻辑方式返回一组数据的查询。 如果选择多维源（如 SAP BW），则只能选择该源。
当加载数据时，任何数据都不会导入到 Power BI Desktop 中，而只会加载架构。 当在 Power BI Desktop 内生成视觉对象时，查询将发送到底层源以检索必要的数据。 刷新视觉对象所花的时间取决于底层数据源的性能。
如果对底层数据进行更改，由于高速缓存原因，这些更改不会立即反映在 Power BI 现有的视觉对象中。 需要执行刷新才能看到这些更改。 对于每个视觉对象，都有相应的查询存在，并且这些视觉对象会相应地更新。
当将报表发布到 Power BI 服务时，它将在 Power BI 服务中产生一个与导入相同的语义模型。 但是，该语义模型不包含任何数据。
当在 Power BI 服务中打开现有报表或构建新报表时，系统将再次查询底层源以检索必要的数据。 根据原始源的位置，可能必须配置本地数据网关。
可以将视觉对象或整个报表页固定为仪表板磁贴。 磁贴按计划（例如每小时）自动刷新。 可以控制此刷新的频率，以满足要求。 打开仪表板时，磁贴会反映上次刷新时的数据，可能不包含对底层数据源进行的最新更改。 始终可以刷新打开的仪表板，以确保它是最新的。
DirectQuery 连接的局限性
使用 DirectQuery 可能会产生负面影响。 其局限性因所使用的特定数据源而异。 应考虑以下几点：
性能 - 如前所述，整体用户体验在很大程度上取决于底层数据源的性能。
安全性 - 如果在 DirectQuery 模型中使用多个数据源，请务必了解数据在底层数据源之间的移动方式以及相关的安全影响。 您还应确定安全规则是否适用于底层源中的数据，因为在 Power BI 中，每个用户都可以看到该数据。
数据转换 - 与导入的数据相比，来自 DirectQuery 的数据在使用 Power Query 编辑器应用数据转换技术时存在一些局限性。 例如，如果连接到 OLAP 源（如 SAP BW），则无法进行任何转换；整个外部模型都取自数据源。 如果要对数据进行任何转换，则需要在底层数据源中执行此操作。
建模 - 使用 DirectQuery 时，导入数据所具有的某些建模功能会不可用，或受到限制。
报告 - 对于 DirectQuery 模型，也支持导入数据所具有的几乎所有报告功能，前提是底层源提供了适当的性能级别。 不过，在 Power BI 服务中发布报表时不支持“快速见解”和“问答”功能。 此外，使用 Excel 中的浏览功能可能会导致性能较差。
有关使用 DirectQuery 的局限性的更多详细信息，请参阅使用 DirectQuery 的影响。
现在，您已经简单了解了 DirectQuery 的工作原理及其局限性，可以采取措施来提高性能。
优化性能
继续以 Tailwind Traders 场景为例，在审查语义模型时，您发现查询使用了 DirectQuery 将 Power BI Desktop 连接到源数据。 使用 DirectQuery 是用户遇到报表性能不佳问题的原因。 加载报表页花费的时间太长，并且在进行某些选择时表刷新速度较慢。 需要采取措施来优化 DirectQuery 模型的性能。
可以检查要发送到底层源的查询，并尝试确定查询性能不佳的原因。 然后，可以在 Power BI Desktop 和底层数据源中做出更改，以优化整体性能。
在 Power BI Desktop 中优化数据
尽可能优化数据源后，可以在 Power BI Desktop 中使用性能分析器来采取进一步措施，即隔离查询以验证查询计划。
可以分析发送到底层源的查询的持续时间，以确定需要较长时间进行加载的查询。 换句话说，可以确定瓶颈存在于何处。
优化 DirectQuery 模型时，无需使用特殊方法；可以应用对导入数据使用的相同优化技术来调整来自 DirectQuery 源的数据。 例如，可以减少报表页上的视觉对象数，或减少视觉对象中使用的字段数。 还可以删除不需要的列和行。
有关如何优化 DirectQuery 查询的更多详细指导，请参阅：Power BI Desktop 中的 DirectQuery 模型指导和成功使用 DirectQuery 的指导。
优化底层数据源（连接的数据库）
第一站是数据源。 您需要尽可能地调整源数据库，因为您对提升该源数据库性能所做的任何改进都会相应地提升 Power BI DirectQuery 的性能。 在该数据库中执行的操作将发挥很大的积极作用。
请考虑使用以下适用于大多数情况的标准数据库做法：
避免使用复杂的计算列，因为计算表达式会嵌入到源查询中。 将表达式推送回源会更高效，因为这样可避免向下推送。 还可以考虑将代理键列添加到维度类型表中。
检查索引并验证当前索引编制是否正确。 如果需要创建新索引，请确保它们是合适的。
请参阅数据源的指导文档并实施其性能建议。
自定义查询缩减选项
Power BI Desktop 为您提供发送更少的查询并禁用特定交互的选项，如果生成的查询需要很长时间才能运行，则会导致体验不佳。 应用这些选项可防止查询持续命中数据源，从而改进性能。
在本示例中，您会编辑默认设置，以便将可用的数据缩减选项应用于模型。 您可以选择文件 > 选项和设置 > 选项，向下滚动页面，然后选择查询缩减选项。
可使用以下查询缩减选项：
减少由以下对象发送的查询数 - 默认情况下，每个视觉对象都与每个其他视觉对象交互。 选中此复选框会禁用这种默认交互。 随后，可以选择使用编辑交互功能来选择相互交互的视觉对象。
切片器 - 默认情况下，立即应用切片器更改选项处于选中状态。 要强制让报表用户手动应用切片器更改，请选择向每个切片器添加应用按钮，以在准备就绪时应用更改选项。
筛选器 - 默认情况下，立即应用基本筛选器更改选项处于选中状态。 要强制让报表用户手动应用筛选器更改，请选择以下替代选项之一：
向所有基本筛选器添加应用按钮，以在准备就绪时应用更改
将单个应用按钮添加到筛选器窗格，以一次性应用更改(预览)
