快速查询在 SSRS 中运行缓慢

在不执行实际报告的情况下，只需在报告服务的 data 选项卡中运行 sproc 即可。还需要时间吗？ 另一种选择是使用 SQLProfiler 并确定数据库系统中进出的内容。

您还可以做另一件事情来测试它，以便在没有任何参数的情况下重新创建一个简单的报告。运行这个报告，看看是否有所不同。您的 RS 报表可能已损坏或形式不良，这可能会导致呈现非常缓慢。

谢谢你在这里提供的建议。我们已经找到了一个解决方案，它确实与参数有关。由于“参数嗅探”，SQLServer 在从 SSRS 报告执行时生成了一个复杂的执行计划。解决方案是在存储过程中声明变量，并将传入的参数分配给变量。然后查询使用变量而不是参数。这导致无论是从 SQLServer 管理器还是通过 SSRS 报表调用查询，查询都执行一致的操作。

我遇到过类似的问题，即我的存储过程从 ManagementStudio 快速执行，但从 SSRS 执行得非常慢。经过长时间的努力，我通过物理删除存储过程并重新创建它来解决这个问题。我不确定其背后的逻辑，但我认为这是因为存储过程中使用的表结构发生了变化。

把这个添加到你的程序结尾: option(recompile)

这将使报表的运行速度几乎与存储过程一样快

I had the same scenario occuring..Very basic report, the SP (which only takes in 1 param) was taking 5 seconds to bring back 10K records, yet the report would take 6 minutes to run. According to profiler and the RS ExecutionLogStorage table, the report was spending all it's time on the query. Brian S.'s comment led me to the solution..I simply added WITH RECOMPILE before the AS statement in the SP, and now the report time pretty much matches the SP execution time.

我要补充的是，我在非存储过程查询中遇到了同样的问题——只是一个普通的 select 语句。为了解决这个问题，我在数据集 SQL 语句中声明了一个变量，并将其设置为等于 SSRS 参数。

多么烦人的变通方法! 不过，还是谢谢你们让我接近答案！

我也面临着同样的问题，对我来说，这只是一个选择:

Tablix 属性 = > 分页选项 = > 尽可能放在一个页面上

它试图将所有记录放在同一个页面上，而不是创建多个页面。

我只是在 Tablix 属性中取消了“在每个页面上重复标题列”的选择。

我也有同样的问题，下面是我对这个问题的描述

“我创建了一个存储过程，可以生成2200行，并且在从 SSRS 2008调用存储过程并运行实际上从未运行过的报告之后，可以在近2秒内执行，最终我不得不从任务管理器关闭 BIDS (Business Intelligence development Studio)。”。

我尝试: 我尝试从 reportuser Login 运行 SP，但 SP 对于该用户也正常运行，我检查了 Profiler，但没有任何结果。

解决方案:

实际上，问题在于，即使 SP 生成了结果，但 SSRS 引擎仍然需要花时间读取这么多行并将其呈现回来。 So I added WITH RECOMPILE option in SP and ran the report .. this is when miracle happened and my problem got resolve.

除了参数嗅探问题之外，我还发现 SSRS 在客户端处理通常比 Crystal 报告(在我的例子中)慢。当 SSRS 引擎有很多行要本地筛选或聚合时，它似乎就不那么有能力了。当然，这些是结果集设计问题，可以经常处理(虽然不总是如果细节需要钻取) ，但是更加成熟的... 报告引擎是更加宽容的。

如果存储过程使用 链接服务器或 Openquery，它们可能会自己快速运行，但在 SSRS 中呈现需要很长时间。一些一般性建议:

• 使用不同的数据源直接从存储数据的服务器检索数据，而不是使用链接服务器检索数据。
• 在执行报表之前，将数据从远程服务器加载到本地表，从而使报表查询保持简单。
• 使用表变量首先从远程服务器检索数据，然后与本地表联接，而不是直接返回与链接服务器的联接。

我看到这个问题已经得到了回答，我只是添加了这一点，以防有人有同样的问题。

遇到同样的问题，通过为共享数据集提供默认参数并在报表服务器中更新该数据集修复了这个问题。

我在检索32000行报表时遇到了报表 html 输出问题。查询速度很快，但是输出到网页浏览器的速度非常慢。在我的情况下，我必须激活“交互式分页”，以允许用户看到第一页，并能够生成 Excel 文件。这种解决方案的优点是第一页显示快，用户可以生成导出到 Excel 或 PDF，缺点是用户只能滚动当前页面。如果用户想看到更多的内容，她必须使用网格上方的导航按钮。在我的案例中，用户接受了这个行为，因为导出到 Excel 更重要。

要激活“ InteractivePaging”，您必须单击报表窗格中的空闲区域，并在“属性”窗格中的报表级别上更改属性“ InteractiveSize”“ Height”。将此属性设置为与0不同。我设置为8.5英寸。还要确保在 Tablix 级别上未选中“尽可能保持在一个页面上”属性(右键单击 Tablix，然后单击“ Tablix 属性”，然后单击“常规”“分页选项”)。

在 SSRS 表中使用“ group by”吗？

我有一个按字段分组的3个报告，我注意到尽管有一个轻微的查询，但是报告运行得非常慢，以至于我甚至不能在搜索字段中拨号。

然后我移除了分组，现在报告在几秒钟内就会显示出来，一切都在瞬间运行。

在我们的例子中，不需要任何代码。

从我们的帮助台注意: “清除您的互联网设置将解决这个问题。”

也许意思是“清除缓存”

我可以通过从底部移除[ & TotalPages ]内置字段来解决这个问题。时间从几分钟下降到一秒钟以内。

一些我无法确定的奇怪的事情正在影响总页数的计算。

我在用 SSRS 2012。

在我的情况下，我只需要断开连接并连接 SSMS。我对查询进行了概要分析，显示执行时间为1分钟，尽管查询本身运行时间不到2秒。重新启动连接并再次运行，这次持续时间显示了正确的执行时间。