Power BI 中的文本搜索性能

在 2022年 2月版Power BI Desktop 的博客文章中，简要介绍了Power BI中针对在文本列中执行搜索的筛选器的新优化。在这篇文章中，将分享有关此优化的更多详细信息，以及如何确保你的报告可以从中受益。

首先，简要描述一下问题。假设你有一个仅包含下表的Power BI 数据集：

假设你要生成一个报表，用户可以在其中搜索“Description”字段中的某些文本内容，并在报表中显示筛选后的结果：

我们将“描述”字段拖到“筛选器”窗格中，筛选器类型设置为“高级筛选”，下拉列表选择了“包含”并且搜索词为“cirus”时显示项目。因此左侧的表仅显示描述中包含文本“cirus”的水果。

下面是为此屏幕截图中的表视觉对象生成的DAX 查询：

如你所见，此查询中的筛选器是使用DAX Search（）函数完成的。这是一个很好的例子，说明我所说的优化可以加快查询类型。

以下是有关此优化如何运作的更多详细信息：

此优化现已启用，在Power BI Desktop 和Power BI 服务中的工作方式相同。

首次计算对文本列使用Search（）或 ContainsString（）DAX 函数的任何查询或度量值时，PowerBI 开始仅为该列生成特殊文本索引。

仅当满足两个条件时，此索引生成才会成功：

文本列只能包含经典128 个字符ASCII 集中的字符。

索引生成必须少于 25秒。如果 25秒过去，则生成将超时，PowerBI 将继续运行查询，而索引不存在。

如果该列的索引生成成功，则所有用户的所有后续查询都可以使用该索引，但在以下情况下将删除该索引：

Power BI Desktop 将重新启动（如果你在Power BI Desktop 中）。

数据集将在 PowerBI Desktop 或 PowerBI 服务中刷新。

数据集将从 PowerBI 服务中的内存中逐出，或者在数据集面临内存压力时逐出。

使用该索引的 DAX查询将比不使用索引的查询快得多，尽管只有在搜索包含数千行的表和具有相当长的文本值的列时，差异才会很明显。

遗憾的是，你无法知道是否已生成索引或生成是否失败，或者DAX 查询是否使用索引。但是，如果查看执行此类搜索的DAX 查询的持续时间（例如，在Log Analytics中或通过运行探查器跟踪），并且看到刷新后的第一个查询相对较慢，并且后续查询几乎是即时的，则很可能已成功生成索引;另一方面，如果你的查询一直很慢，则索引可能尚未成功构建。

如何确保索引构建成功？确保保持在25秒超时限制以下的唯一方法是减少需要编制索引的文本量，方法是减少表中的行数或减少列中的文本量。减少列中的文本量可能是唯一可行的选择：例如，你可以从文本中删除“and”和“the”等单词，因为用户不太可能需要搜索它们。

转载：

https://blog.crossjoin.co.uk/2023/03/05/text-search-performance-in-power-bi/