我花了几个小时对此进行排查，我需要一些新观点。 。
我们在SSRS中设置了一个相对简单的报表，简单的矩阵包含顶部的列和数据点。报告背后的SQL查询是“中等”复杂性 - 有一些子查询和几个连接，但没有什么真正的疯狂。
报告已经好几个月了，最近变得非常慢。比如，生成报告需要15-20分钟。我可以将SQL查询从报表设计器剪切并粘贴到SQL Mgmt Studio中，替换必要的变量，并在不到2秒的时间内完成结果。我甚至使用SQL分析器来获取SSRS正在执行的完全查询，并将其剪切并粘贴到Mgmt Studio中，仍然是同样的，亚秒结果。指定的参数和日期范围没有任何区别，我可以设置参数以返回小数据集（＆lt; 100行）或大数据集（＆gt; 10,000行），并且结果仍然相同;在Mgmt Studio中超快，但生成SSRS报告需要20分钟。
故障排除我到目前为止尝试过： 在SSRS中删除并重新部署报告。 在多台机器和SSRS服务器上的Visual Studio IDE中测试，两个地方的速度相同（约20分钟） 使用SQL事件探查器监视执行报告的SPID，捕获正在执行的所有SQL语句，并在Mgmt Studio中单独（和一起）尝试它们 - 在Mgmt Studio中快速运行（<2秒） 报告执行期间监视的服务器性能。在生成20分钟报告期间，处理器非常重要，磁盘I / O略高于基线
答案 0 :(得分：6)
检查两者的执行计划，以确保参数嗅探和/或set_options中的差异的组合没有生成两个单独的执行计划。
这是我在从ADO.Net和SSMS执行查询时遇到的情况。当使用不同的选项创建不同的执行计划时，会出现问题。 SQL Server利用传入的参数值来尝试进一步优化生成的执行计划。我发现每个生成的执行计划都使用了不同的参数值，从而产生了最优和次优计划。我目前无法找到原始查询来查看此内容，但快速搜索显示此文章与同一问题有关。
如果你正在使用SQL Server 2008，还有一个通过查询提示提供的替代方案叫做“OPTIMIZE FOR UNKNOWN”，这实际上禁用了参数嗅探。以下是一篇文章的链接，该文章帮助了我对此功能的原创研究。
对于早于2008的版本，上述替代方法是将参数值存储在过程中的局部变量中。这与上面的查询提示的行为方式相同。这个提示来自下面的文章（在编辑中）。
修改
更多的搜索结果发现了一篇文章，对该主题进行了非常深入的分析，如果有任何用处，请链接如下。
答案 1 :(得分：3)
这个问题对我们来说也是一个问题。我们正在运行CRM 2011中的SSRS报告。我已经尝试了一些建议的解决方案（将输入参数映射到局部变量，将WITH RECOMPILE添加到存储过程中），但没有任何运气。
本文介绍了报表服务器应用程序内存配置（http://technet.microsoft.com/en-us/library/ms159206.aspx），更具体地说，将4000000值添加到RSReportServer.config文件中解决了这个问题。
渲染需要30-60秒的报告现在在不到5秒的时间内完成，这与底层存储过程在SSMS中执行的时间大致相同。