SSRS 报告运行速度非常慢，而查询在 SSMS 中运行速度超快答案

【问题标题】：SSRS report running very slow whereas the query runs super fast in SSMSSSRS 报告运行速度非常慢，而查询在 SSMS 中运行速度超快
【发布时间】：2013-04-03 14:36:47
【问题描述】：

我在 SSRS 2012 中运行一个非常基本的报告。我只是从表中检索一些数据，并且我在查询的 Where 子句中使用了一个参数。如果我对 SSRS 查询中的参数进行硬编码，则查询运行速度很快（不到 5 秒），但如果将其保留为动态选择的参数，则查询需要 5 分钟以上才能呈现。这是一个类似于我正在使用的抽象查询：

Select Col1, Count(*)
From Tbl1
Where Col2 = @Para1
Group By Col1
OPTION (RECOMPILE);

我已经尝试在查询中使用 OPTION (RECOMPILE) 来解决参数嗅探问题。我还检查了数据类型，Col2 是 CHAR(2)，Para1 是 TEXT，所以在运行时不需要转换。

有什么想法可能导致这种情况吗？

【问题讨论】：

尝试在 SQL Mgmt studio 中运行带有参数和不带参数的查询（硬编码）。看看执行计划是否不同。
您可以使用 COUNT(1) 来避免处理 COUNT(*) 中的所有列。相同的输出。
尝试使用stored procedures而不是ad-hoc查询

标签： reporting-services

【解决方案1】：

我也遇到过类似的问题，但只是在连接到 Oracle 数据库时。当我对查询中的参数进行硬编码时……效果很好……将参数传递给查询，这将需要很长时间。奇怪的是，某些参数只需要永远。在我的情况下，当我检查日志时，渲染时间是永远的。（还应该提到这是一个多选参数...无法解决）

奇怪的解决方案：

我没有将参数传递给查询，而是将其作为过滤器传递给数据集。有人会认为这只会增加 ssrs 服务器的负载，因为您要通过网络发送更多数据以供其处理……从而增加渲染时间，但区别在于白天和黑夜。报告现在运行良好。

老实说无法解释。

我写的报告比我对 SQL Server 数据源的数量还要多，而且我只在连接到 Oracle 时看到了这个（以及一些其他奇怪的事情）。但是，如果您遇到同样的问题，可能值得一试，并且您应用的参数实际上并没有限制数据那么多。（就我而言，大多数人都在运行“全部”。

如果您不熟悉在数据集上使用过滤器。转到此链接并查找标题“使用具有多值参数的过滤器”（也适用于非多值参数）http://www.mssqltips.com/sqlservertip/2866/sql-server-reporting-services-using-multivalue-parameters/

【讨论】：

【解决方案2】：

我遇到了同样的问题。我运行了 SQL Server Profiler Sniffing queries to SQL Server 确定报告慢的地方，发现一个查询运行了 20 秒。查询包装在 exec sp_executesql 中。我将查询复制到 SSMS 并发现它运行了 20 秒。将查询转换为直接 SQL 使其运行 1 秒。啊哈！

返回exec sp_executesql sql，果然有IN子句：

operid IN  (N''XICL002'',N''XICL005'',N''XICL026'',N''XICL028'...

operid 是 decared varchar(32) 而 N 前缀将参数强制为 NVARCHAR。删除 N 使 exec sp_executesql sql 在 1 秒内运行。

就我而言，我能够修改报告。 IN 子句由多选参数 (p_operators) 填充。我更改了报告查询以使用生成 p_operators 列表的参数从视图中获取操作符列表。

operid IN (SELECT oper_id  FROM foo WHERE (foo1 IN (@p_foo1)) AND (foo2 IN (@p_foo2)) AND ...

基本上，将参数从 NVARCHAR 转换为 VARCHAR 会降低性能。似乎 SSRS 应该提供指示参数数据类型的选项 - 而不仅仅是“文本”。此外，在开发模式下记录一些查询也会很好。

（我希望我提供的信息足够有用。由于公司政策，我不能写太多）

【讨论】：

我的问题不是使用 IN 原因，而是您的声明“基本上，将参数从 NVARCHAR 转换为 VARCHAR 正在扼杀性能。”是完全相同的问题。我在SQL里面加了一个CONVERT语句围绕参数使用，性能从5分钟到秒。

【解决方案3】：

我在使用查询加载数据的报告中遇到了类似的问题。就我而言，我必须支持架构团队建立的开发模式（在 SSRS 数据集中使用直接查询）。我不能使用过滤器，因为未过滤的数据量和安全要求（仅从数据库中提取请求的数据）。

所以我的解决方案是攻击转换。我声明了表变量，用来自 SSRS 参数的转换选择值填充这些变量，并在 WHERE … IN (…) 表达式中使用这些表变量。这涵盖了仅查询、有限数据量、安全数据访问的所有要求，并解决了 NVARCHAR 到 VARCHAR 转换速度的问题。

查询中的解决方案如下所示（@pSelectedValues 是映射到报告中选择参数的变量，在我更改之前它已经存在）：

DECLARE @tMySelectedParameterValues TABLE( SelectedValue varchar(255) NULL );

INSERT INTO @tMySelectedParameterValues

SELECT DISTINCT EntityStatusStatusName
FROM      dbo.t_MyReferenceData
WHERE     ValueForParameters IN (@pSelectedValues);

... main selection and from parts ....

WHERE keyValues IN (SELECT SelectedValue FROM   @tMySelectedParameterValues )

【讨论】：

【解决方案4】：

三件事：

为什么必须使用重新编译？除非您的计划在每次不需要时都特别想重新考虑它的执行。特别是如果您要说明您的查询很简单。 SSRS 在 SQL 之上做了它自己的解释，所以为它添加更多的东西只是在自找麻烦。如果您必须重新编译，您可能希望将其放在 proc 中，以便封装所有逻辑以供 SQL 引擎理解。
参数有时会减慢任何东西 SSMS 中带有参数的查询是否也很慢？您提到它是快速硬编码的，但没有在 SSMS 中使用参数对其进行测试。我有时看到 SSMS 上的参数很慢。
您可以“欺骗”SSRS 的参数部分，只需稍加了解即可。在参数特别糟糕的极端情况下，您可以构建一个在运行时运行的表达式。在您的数据集选项上，单击表达式的“fx”，然后执行以下操作：
```
="Select Col1, Count(*)
From Tbl1
Where Col2 = " & Parameters!Para1.Value
```

只要您的类型是文本，这应该会产生一个合法的字符串，然后在运行时进行评估。需要注意的是，您的字段可能不会首先自行填充，因此您可能希望进行实际查询，让它们自动填充，然后返回并将函数放入。否则您将不得不在左侧窗格中手动设置字段指出“字段”的数据集，恕我直言，这很痛苦。

【讨论】：