reporting-services - 快速查询在 SSRS 2 中运行缓慢

Question

这基本上与“快速查询在 SSRS 中运行缓慢”相同，但是我看不出其中对我有用。

上下文: 创建了一个用于我的报告的报告生成器数据集，查询是:

SELECT  DISTINCT A.A
,   A.B
,   A.C
,   A.A + ', (' + A.B + '), : ' + CAST(A.C AS VARCHAR) D
FROM Table1 X
INNER JOIN TableA A ON X.Key = A.Key
WHERE (X.Col1 IN (@Param1))
AND (X.Col2 IN (@Param2))
UNION
SELECT '(All)', '(Select to apply all)', 0, '<APPLY ALL>'
ORDER BY C, A
OPTION (OPTIMIZE FOR UNKNOWN)

我有 3 个多值参数。第一个 (@Param1) 和第二个 (@Param2) 列出了负载良好，第二个不依赖于第一个。正如您从上面的查询中看到的那样，使用上述数据集的第三个列表依赖于 1 和 2。

我添加了 OPTION (OPTIMIZE FOR UNKNOWN) 子句来尝试加快速度，但没有效果。我什至不知道如何声明多值参数，所以这是我现阶段尝试的唯一选择。

在我从第二个下拉列表/参数中选择值并移至第三个参数后，报告加载图标会搅拌大约 5 秒，然后停止，之后什么也没有发生，而且我永远无法从第三个下拉列表中进行选择除非我准备等到它完成，但这似乎需要大约 20 分钟，所以过了一会儿我就杀死该网页并重新开始。当我在一秒钟内运行 SQL Server 中的报表查询时，当我在报表生成器 IDE 中运行报表时，与 20 分钟相比，它工作得很好，有一点延迟，如几秒，但通过 SharePoint/SSRS 运行则需要 20 分钟。

有人有尝试的建议吗？

Answer 1

我发现自己的解决方案更多的是出于偶然，而不是巧妙的想法，这纯粹是我的一个错误，很抱歉浪费了任何人的时间，但它仍然让我有点困惑，或者也许用恼火是更好的描述方式。

显然，我提高性能的尝试之一还包括缓存大约一周前完成的数据集。我按照特定的每日计划打开了“缓存共享数据集”，但是没有“缓存刷新计划”(如果这有影响的话) - 可能会这样做，因为它可能仍在使用缓存版本，即也许更改数据集实际上并不会强制执行在报表的下拉列表中加载数据时自动刷新。因此，在设置缓存后更新查询的过程中，我从直接的 sql 变为多语句表值函数(使用未知选项优化)，然后变为调用我的函数的存储过程。因此，在更新数据集中的查询并刷新由于缓存而使用该数据集的报告后，它可能没有应用我的最新更改。我关闭了缓存，然后我的报告第三个参数(Dropdown)开始响应。在 SharePoint 中运行时仍然相当慢，但在报表生成器 IDE 中运行时它是瞬时的，下降到大约 10 秒，而不是无限长的时间。因此，我剩下的问题是使用实际上有效的存储过程，还是我在查询上使用了该选项，以及是否缓存是否会导致不明显的问题(即不会刷新)直到下一个预定时间段，我不确定制定“缓存刷新计划”是否会产生任何影响。更重要的是，为什么像 MS Server Management Studio 那样通过 SharePoint 运行查询要复杂得多，我确信如果我编写自己的自定义网页来调用相同的查询，它也会是即时的 - 无论如何，事情都会发生回去尝试一下是否可以打扰我。

显然，数据随着时间的推移而变化，类似于该网站上另一篇文章的报告工作正常，然后突然变得没有响应，无论如何它现在工作得足够好，不需要缓存。