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

这基本上是同一个问题，因为快速查询在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

我添加了optionoptimizeforunknown子句，试图加快速度，但没有效果。我甚至不知道如何声明多值参数，所以这是我在这个阶段尝试的唯一选项

在我完成从第二个下拉列表/参数中选择值并移动到第三个参数后，报告加载图标会旋转大约5秒，然后停止，之后什么也没有发生，我永远无法从第三个下拉列表中选择，除非我准备等待它完成，但这似乎是20秒左右几分钟后，过了一会儿，我就关掉网页，重新开始。在SQL Server中运行报表查询只需一秒钟，在报表生成器IDE中运行报表查询只需几秒钟，而通过SharePoint/SSRS运行则需要20分钟

---

有人建议我试试吗？

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

显然，我提高性能的一个尝试还包括缓存一周前完成的数据集。我使用特定的每日计划打开了缓存共享数据集，但是如果这会产生影响，则没有缓存刷新计划-可能会发生这种情况，因为它可能仍然使用缓存版本，也就是说，在报告的下拉列表中加载数据时，更改数据集实际上不会强制自动刷新。因此，在我设置缓存之后更新查询的过程中，我从纯sql转换为带有optimize for unknown选项的多语句表值函数，然后转换为调用我的函数的存储过程。因此，在更新数据集中的查询并刷新由于缓存而使用数据集的报表后，它可能没有应用我的最新更改。我关闭了缓存，然后我的报告第三个参数下拉列表开始响应。在SharePoint中运行时仍然有点慢，而在ReportBuilderIDE中，它是即时的，但与无限长的时间相比，它只需10秒左右。所以我剩下的问题是，使用存储过程实际上是有效的，还是我在查询中使用了该选项，以及如果它将导致一个不明显的问题，是否要缓存，也就是说，直到下一个计划周期才会刷新，我不确定是否有缓存刷新计划，这是否会产生任何影响。更重要的是，为什么通过SharePoint向MS Server Management Studio运行查询要复杂得多？我确信，如果我编写自己的自定义网页调用相同的查询，它也将是即时的——不管怎样，如果我感到麻烦的话，可以回到实验中去

---

很明显，数据会随着时间的推移而变化，而且与此站点上的另一篇文章类似的报告工作得很好，然后突然变得没有响应，不管怎样，它现在工作得很好，不需要缓存。

您通常希望从该数据集中获得多少行？还有，您使用UNION而不是UNION ALL的特殊原因吗？行数小于40000。我现在使用UNION ALL没有任何区别。我还将数据集中的查询改为使用多语句表值函数，希望可以创建一个查询计划来尝试优化，但是在报表生成器IDE中仍然需要不到一秒钟的时间，但通过SharePoint网站，这需要永远的时间