这与“快速查询在SSRS中运行速度慢”基本相同，但我认为没有什么能为我工作。
上下文： 创建了用于我的报告的Report Builder数据集，查询为：
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分钟。
有人有建议尝试吗？
答案 0 :(得分：1)
我偶然发现了自己的解决方案，而不是巧妙的想法，这对我而言纯粹是一个错误，所以很遗憾浪费任何人的时间，但它仍然让我有点困惑，或者可能是生气，这是一种更好的方式来形容它。
显然，我提高性能的尝试之一还包括缓存DataSet，这是在大约一周左右完成的。我使用特定的每日时间表启用了“缓存共享数据集”，但是如果有所不同则没有“缓存刷新计划” - 可能是因为它可能仍然使用缓存版本，即可能更改数据集实际上并不强制执行在报表的下拉列表中加载数据时自动刷新。所以在更新我的查询的过程中，在我设置了缓存之后，我从直接的sql转到了多语句表值函数（选项优化为未知），然后是一个调用我的函数的存储过程。因此，在更新数据集中的查询并刷新由于缓存而使用数据集的报表后，可能不会应用我的最新更改。我关闭了缓存，然后我的报告第三个参数（Dropdown）开始响应。在SharePoint中运行时仍然相当慢，在报表生成器IDE中它是瞬时的，但是大约10秒而不是无限的时间。所以我留下的问题是使用实际有效的存储过程，或者是我在查询上使用选项的事实，并进一步缓存或不缓存，如果它将导致非明显的问题，即不会刷新直到下一个预定的时间段，我不确定是否有“缓存刷新计划”是否会产生任何影响。而且更重要的是，为什么通过SharePoint运行查询应该对MS Server Management Studio这么复杂，我相信如果我编写自己的自定义网页，调用相同的查询它也会是即时的 - 无论如何要去的东西回去试验我是否可以被打扰。
显然数据会随着时间的推移发生变化，报告与此站点上的另一篇文章类似，但是突然之间它变得无法响应，无论如何它现在已经足够好了，而且不需要缓存。