使用表级别存储优化 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 连接的行为
在 Power BI Desktop 中使用 DirectQuery 连接到数据时，该连接的行为方式如下：
最初在 Power BI Desktop 中使用“获取数据”功能时，你会选择源。 如果连接到关系源，则可以选择一组表，每个表会定义一个以逻辑方式返回一组数据的查询。 如果选择多维源（如 SAP BW），则只能选择该源。
加载数据时，不会将任何数据导入 Power BI Desktop 中，只会加载架构。 在 Power BI Desktop 中构建视觉对象时，查询会发送到基础源以检索所需数据。 刷新视觉对象所花的时间取决于基础数据源的性能。
如果对基础数据进行了更改，则由于缓存，它们不会立即反映在 Power BI 中的现有视觉对象中。 需要执行刷新才能看到这些更改。 为每个视觉对象提供必要的查询，视觉对象会相应地进行更新。
将报表发布到 Power BI 服务时，它将在 Power BI 服务中产生语义模型，与导入相同。 但是，该语义模型中不包含任何数据。
在 Power BI 服务中打开现有报表或构建新报表时，会再次查询基础源以检索所需数据。 根据原始源的位置，可能必须配置本地数据网关。
可以将视觉对象或整个报表页固定为仪表板磁贴。 磁贴按计划（例如每小时）自动刷新。 可以控制此刷新的频率，以满足要求。 打开仪表板时，磁贴会反映上次刷新时的数据，可能不包含对基础数据源进行的最新更改。 始终可以刷新打开的仪表板，以确保它保持最新状态。
DirectQuery 连接的限制
使用 DirectQuery 可能会产生负面影响。 限制因所使用的特定数据源而异。 应考虑以下几点：
性能 - 如前所述，整体用户体验在很大程度上取决于基础数据源的性能。
安全 - 如果在 DirectQuery 模型中使用多个数据源，请务必了解数据在基础数据源之间的移动方式以及关联安全影响。 还应该确定安全规则是否适用于基础数据源中的数据，因为在 Power BI 中，每个用户都可以看到该数据。
数据转换 - 与导入的数据相比，当涉及到在 Power Query 编辑器中应用数据转换技术时，源自 DirectQuery 的数据具有限制。 例如，如果连接到 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 提供了相应选项来发送较少查询以及禁用在生成的查询需要较长时间运行时会导致体验不佳的某些交互。 应用这些选项可防止查询持续命中数据源，从而改进性能。
在此示例中，你会编辑默认设置，以便将可用的数据缩减选项应用于模型。 通过选择“文件”>“选项和设置”>“选项”，向下滚动页面，然后选择“查询缩减”选项，可访问设置。
有以下查询缩减选项可用：
减少由以下对象发送的查询数 - 默认情况下，每个视觉对象都与每个其他视觉对象交互。 选中此复选框会禁用这种默认交互。 随后你可以选择使用“编辑交互”功能来选择相互交互的视觉对象。
切片器 - 默认情况下，“立即应用切片器更改”选项处于选中状态。 若要强制报表用户手动应用切片器更改，请选择“向每个切片器添加应用按钮，以在准备就绪时应用更改”选项。
筛选器 - 默认情况下，“立即应用基本筛选器更改”选项处于选中状态。 若要强制报表用户手动应用筛选器更改，请选择其他选项之一：
向所有基本筛选器添加应用按钮，以便在准备就绪时应用更改
将一个应用按钮添加到此筛选器窗格，以便一次性应用更改(预览)
