sql-server-2008-r2 - SSRS 报告在 prod 中非常慢，但 SQL 查询运行得很快

Question

我花了几个小时来解决这个问题，我需要一些新的视角。 . .

我们在 SSRS 中有一个相对简单的报告设置，简单的矩阵，列在顶部，数据点向下。报告背后的 SQL 查询是“中等”复杂性——有一些子查询和几个连接，但没有什么真正的疯狂。

报告几个月来一直运行良好，最近变得非常缓慢。比如，生成报告需要 15-20 分钟。我可以将报表设计器中的 SQL 查询剪切并粘贴到 SQL Mgmt Studio 中，替换必要的变量，并在不到 2 秒的时间内生成结果。我什至使用 SQL 分析器来获取 SSRS 正在执行的确切查询，并将其剪切并粘贴到 Mgmt Studio 中，仍然是同样的事情，亚秒级结果。指定的参数和日期范围没有任何区别，我可以设置参数以返回一个小数据集(< 100 行)或一个庞大的数据集(> 10,000 行)并且结果仍然相同；在 Mgmt Studio 中超快，但生成 SSRS 报告需要 20 分钟。

到目前为止我尝试过的故障排除:
删除并重新部署了 SSRS 中的报告。
在多台机器和 SSRS 服务器上的 Visual Studio IDE 中测试，两个地方的速度相同(约 20 分钟)
使用 SQL Profiler 监控执行报告的 SPID，捕获所有正在执行的 SQL 语句，并在 Mgmt Studio 中单独(和一起)尝试它们——在 Mgmt Studio 中运行速度很快(< 2 秒)
在报告执行期间监控服务器性能。处理器在 20 分钟的报告生成过程中受到了相当大的打击，磁盘 I/O 略高于基线

Answer 1

检查两者的执行计划以确保参数嗅探和/或 set_options 中的差异的组合没有生成两个单独的执行计划。

这是我在从 ADO.Net 和 SSMS 执行查询时遇到的场景。当使用不同的选项创建不同的执行计划时会出现问题。 SQL Server 利用传入的参数值尝试进一步优化生成的执行计划。我发现每个生成的执行计划都使用了不同的参数值，从而产生了最优和次优计划。我目前无法找到用于检查此问题的原始查询，但快速搜索会发现与同一问题相关的这篇文章。

http://www.sqlservercentral.com/blogs/sqlservernotesfromthefield/2011/10/25/multiple-query-plans-for-the-same-query_3F00_/

如果您使用的是 SQL Server 2008，还可以通过名为“OPTIMIZE FOR UNKNOWN”的查询提示提供替代方案，它基本上禁用了参数嗅探。下面是一篇文章的链接，该文章帮助我对此功能进行了原始研究。

http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature.aspx

对于 2008 之前的版本，上述的替代方法是将参数值存储在过程中的局部变量中。这与上面的查询提示的行为方式相同。这个技巧来自下面的文章(在编辑中)。

编辑

多一点搜索发现了一篇文章，该文章对该主题进行了非常深入的分析，以防万一它有任何用处，请点击下面的链接。

http://www.sommarskog.se/query-plan-mysteries.html