为什么 Reporting Services 报告比其查询慢得多？答案

【问题标题】：Why is Reporting Services report vastly slower than its query?为什么 Reporting Services 报告比其查询慢得多？
【发布时间】：2010-03-03 22:19:25
【问题描述】：

我有一个大约需要 2 分钟才能运行的查询。就参数或任何东西而言，它并不是非常复杂，而且报告本身并没有进行任何真正广泛的处理。基本上只是以一种很好的格式直接吐出数据。（实际上其中一份报告根本没有格式化数据，只是返回了一个平面表，打算在 excel 中进行操作。）

它也没有返回大量数据。

但该报告需要 30 多分钟才能运行。

这是什么原因造成的？

这是针对 SQL 2005 数据库的 SSRS 2005 顺便说一句。

编辑：好的，我发现在报告中添加 WITH (NOLOCK) 所需的时间与通过 SSMS 进行查询所需的时间相同。如果查询来自报告服务（或本地计算机上的 Visual Studio），为什么查询的处理方式与来自本地计算机上的 SSMS 的查询不同？我看到查询在 SLEEP_WAIT 模式下在 Activity Monitor 中运行了几次，但没有被任何东西阻止......

EDIT2：连接字符串是：

数据源=SERVERNAME；初始目录=DBName

【问题讨论】：

只是一个怀疑，但我怀疑 datasource/ado.net “驱动程序”是问题所在。我对这方面的任何其他 cmet 感兴趣，并且我有过类似的经历。
报表中数据源的连接字符串是什么样的？
可能相关？ stackoverflow.com/questions/2283943/… 虽然你的 NOLOCK 经验可能不会。

标签： reporting-services reportingservices-2005

【解决方案1】：

确实是查询需要很长时间才能运行，还是服务器执行的处理速度很慢？有些报告会多次调用查询。例如，如果您在分页列表控件的内部有一个子报表，则该报表的每个页面都会单独调用该查询。那么可能是报告正在对导致延迟的数据执行某些操作？

【讨论】：

报告只调用一次查询......正如我所说，报告并没有对数据进行太多处理。一旦我将 WITH NOLOCK 添加到查询中，报告会在 2 分钟内运行...

【解决方案2】：

您的查询返回的数据集有多大？如果它非常大，则在报表服务器上花费的大部分时间可能与呈现报表所花费的时间有关。为了确保您可以查看报表服务器上的 ExecutionLog 表，以了解 TimeRendering 与总体执行时间相比是否很大。

【讨论】：

没那么大，而且为什么NOLOCK会影响报告的速度呢？

【解决方案3】：

我认为这并不少见，但我们研究了类似的问题。

根据记忆，我们确实注意到的一件事是我们的子报表有参数，并且我们已经配置了要从数据库中查询的“可能值”。

我认为每次运行子报表时，SSRS 都会重新查询参数的可能值（并在报表中运行任何其他查询，即使您不使用结果也是如此）。

在这种情况下，一旦我们对子报告工作正常感到满意，我们就删除了用于验证参数值的查询并允许“任何值”，假设父报告不会向我们提供错误的参数值。

【讨论】：

【解决方案4】：

聚会有点晚了，但对于未来遇到类似问题的任何人。

参数嗅探

如果使用带参数的存储过程，可能是由于一种称为“参数嗅探”的现象。

简而言之，第一次从 SSRS 执行存储过程时，会根据指定的参数值确定执行计划。然后，每次从 SSRS 执行存储过程时，都会存储和使用此执行计划。即使这个执行计划对于任何未来的参数值可能都不是最优的。

如需更详细的解释，请查看：https://www.brentozar.com/archive/2013/06/the-elephant-and-the-mouse-or-parameter-sniffing-in-sql-server/

其他问题

也看看这个类似的问题： Fast query runs slow in SSRS

【讨论】：