我有一个存储过程，在SSMS中最多使用2个核心，在10秒内返回大约50000条记录。使用存储过程的SSRS报告需要20分钟，并且会在整个8核服务器上最大化处理器。报告相对简单（即没有图表，计算）。当我将50K行写入临时表时，报告似乎不是问题，报告可以在几秒钟内显示数据。我尝试了许多不同的想法来测试每次更改存储过程，但是将原始代码保存在一个单独的窗口中以恢复为原样。在存储过程的一个Alter之后，返回到原始代码，报告和服务器利用率开始快速运行，与单独的存储过程的性能相当。现在一切都很好，但是我希望能够找到导致这种情况再次发生的原因。有什么想法吗？
答案 0 :(得分：0)
当你正常执行时，我会从存储过程的SQL事件探查器跟踪开始，然后在SSRS调用它时使用相同的SP。确保包含所涉及的执行计划，这样你就可以看出它是否做出了一些错误的决定（虽然这似乎不太可能 - 但无论查询的来源如何，SQL Server都应该执行最佳 - 或至少是一致的）。
我们曾经有过这样的情况：Business Objects会在没有明显原因的情况下执行存储过程数十次并且偶尔会导致糟糕的性能，尽管我从未见过与SSRS相同的行为。不过，它可能在某个地方开始。您还将看到执行开始/结束时间 - 如果数据库层挂起，或者SQL Server在10秒内回退数据，然后是某个地方窒息的SSRS服务，则会清楚显示执行开始/结束时间。
答案 1 :(得分：0)
加速SSRS报告的主要解决方案是缓存报告。如果这样做（例如我在上午7:30预加载缓存）或缓存报告命中，那么会发现加载速度大幅上升。
您可能还会发现每月重新启动SSRS应用程序域以解决您的问题。
请注意我每天和专业这样做，而不是简单地在SSRS上打造诗意
SSRS中的缓存 http://msdn.microsoft.com/en-us/library/ms155927.aspx
预加载缓存 http://msdn.microsoft.com/en-us/library/ms155876.aspx
如果您不喜欢初始报告需要很长时间且数据是静态的，即每日总帐等，这意味着数据在当天相对静态，可能会延长缓存寿命。
最后，您也可以选择业务经理通过电子邮件订阅接收这些报告，这会向他们发送一个他们可能会发现的Excel报告的时间点更系统化。
您还可以使用SSRS中的参数，以便用户轻松解析和更快的查询。在查询构建器中，在希望参数化的“过滤器”列下键入IN（@SSN），然后您将在BIDS GUI左上角的数据源正上方的参数文件夹中找到它。 [如果在SSRS中没有看到数据源部分，请按CTRL + ALT + D.
在此处查看几乎相同的问题：Performance Issuses with SSRS