【发布时间】：2021-11-18 02:47:35
【问题描述】：
我有一个从 SQL Server 拉取的 Power BI 报表，由于拉取大量数据，该报表需要设置为增量刷新。由于负载相当复杂（而且 PQuery 编辑器很乏味并且经常中断折叠），我需要使用 SQL 查询（在 PBI 中也称为“本机查询”），同时保留查询折叠（以便增量刷新工作）。
我一直在用nice...
Value.NativeQuery( Source, query, null, [EnableFolding = true])
... 欺骗found here 让它发挥作用。
但它似乎只有在本机查询完成得相当快的情况下才有效。当我的 WHERE 子句只提取今年的数据时，没问题。当我删除 WHERE 子句中的日期过滤器时（以免与增量刷新过滤器冲突），或者只是将年份往后推，似乎需要更长的时间才能导致 PBI 确定：
"We cannot fold on top of this native query. Please modify the native query or remove the 'EnableFolding' option."
几分钟后在 PQuery 编辑器中出现上述错误，或者如果我尝试通过快速单击“关闭并应用”来“绕过”它。不幸的是，由于我们的数据结构不太好，底层 SQL 可能已经达到了最好的水平。我已经尝试通过脚本中的OPTION (FAST 1) 来欺骗 PBI 看似超时，但它不能足够快地拉出任何东西。
我现在卡住了。这似乎是一个愚蠢的障碍，因为我需要做的就是完成第一次导入，因为很明显它可以查询折叠以获取较短的负载。我该如何解决这个问题？
【问题讨论】：
-
你可以把你的原生sql查询直接放到Sql.Databases中，不用等到Value.NativeQuery。您可以减少一个查询步骤和处理。最重要的部分是通过在谓词列上创建索引来优化 Sql Query。 Stack 对 Sql 查询优化有大量支持。
-
@smpa01 直接放在Sql.Databases中是什么意思？你的意思是作为一种观点吗？无论哪种方式，这种观点都是一个好主意。就索引而言，我们不太可能走得更远。我们的工程团队最终决定，集群列存储可能是我们的最佳选择（巨大的表，大量的谓词）。
-
如果你看Chris的文章，你可以看到第一步是Sql.Databases，第二步是Value.NativeQuery。当您可以简单地在第一步中使用您的查询时，您将 sql 查询放在第二步，并让第一步处理任何查询。此外，根据您的情况，您可以创建表变量（在 TSQL 中）并在表变量中创建索引，将初始查询结果插入其中并继续使用具有索引的表变量中的表。我尝试了 tjis 技术来处理缓慢的 DF 情况，大大提高了我的查询执行能力。
-
@smpa01 我不确定我是否遵循。使用 NativeQuery() 步骤（这是 Chris 博客中的一个单独步骤）的全部意义在于能够使用 [EnableFolding=true] 选项。这在 Sql.Database() 中是不允许的，即使 [Query=...] 是。简单地将本机查询作为源运行会破坏查询折叠（因此是增量刷新）。我也看不出表变量在哪里有帮助。表变量是本地的，所以我必须先在我的查询中插入它，所以从源中提取的初始值不会更快。现在我认为将我的查询存储为服务器上的视图可能会起作用。
-
如果您再次查看 Chris 的查询，他正在 M 中进行过滤（Day=Friday），并且由于在之前的步骤中启用了查询折叠，该过滤被折叠到源。据我所知，如果您没有为转换编写任何服务器端查询，并且您希望所有转换都通过 M 发生，那么启用查询折叠有助于后续步骤，因为等效语法被转换为可折叠源。但在你的情况下，你正在做整个转换服务器端。所以我不知道你是否有任何价值等到第2步启用查询。
标签： sql-server powerbi powerbi-desktop powerbi-datasource