报表服务的性能很慢，在QueryAnalyser中非常快
我们将SQL Server 2005与Reporting Services一起使用。
我们有许多报告，每个报告都包含一个相对简单的SQL查询--“相对”我的意思是我们确实有一些连接，但没有比这更糟糕的了。我们在查询中不调用任何存储过程-这不是参数嗅探的情况。
当通过Reporting Services执行其中一个报告(我们称之为报告A)时，它需要极长的时间才能完成--大约需要几十分钟甚至几个小时。在查询分析器中执行相应的SQL查询时，只需几秒钟即可完成。
从数据库返回的行数可以少到1行-但是，报告永远不会完成。
其他报告运行正常。
查看Reporting Services上的ExecutionLog表，我可以看到大部分时间是以TimeDataRetrieval为单位的(我们在这里讨论的是数百万秒...)--这些时间是报告实际完成的时间。如果手动中止报告，则TimeDataRetrieveal为零，TimeProcessing高得离谱。
我查看了Reporting Services的日志，但一切正常。
现在，在你开始建议"lock“之前--好吧，我们的查询确实开启了nolock提示。
就目前而言，我已经达到了我的想象力的极限，试图找到错误。任何想法，见解都会很高兴地被感谢。
/Christoffer
回答 5
Stack Overflow用户
发布于 2010-02-16 17:33:40
我最终剥离了查询，基本上一次只有一条语句，直到我找到罪魁祸首。查询中的一个联接使用"with (nolock index(x))“提示联接到一个不断增长的表(数百万行)中。
删除查询分析器中的索引提示后，得到的结果与Reporting Services中的结果相同-这是一个very速度很慢的查询。这本身并不令人惊讶-但实际上，当通过RS运行查询时，似乎没有使用该提示。
然后，我使用SET FORCEPLAN ON语句再次尝试在RS中运行报告。还有..。它起作用了-执行时间现在是几秒钟，正如它应该的那样。据我所知，FORCEPLAN选项强制SQL Server按指定的顺序处理联接，并考虑任何提示。
当查询分析器显然将其考虑在内时，有没有人知道为什么通过RS的查询会忽略这个提示？
Stack Overflow用户
发布于 2010-02-16 06:40:19
在运行报告时，尝试使用SQL事件探查器捕获执行计划。如果您没有任何CONVER_IMPLICIT操作符，请查看一下，例如，表/索引扫描。
http://msdn.microsoft.com/en-us/library/ms190233.aspx
转换会阻止索引的使用，如果您传递的参数的类型与您比较它们的列的类型不同，则可能会发生这种情况。
您可能会尝试向报表的查询添加选项(重新编译)，您的报表可能是parameter sniffing的牺牲品。
检查您的查询是否使用标量用户定义函数。它们可能是性能的真正杀手。如果您拥有它们，则可以将它们转换为table valued functions。
Stack Overflow用户
发布于 2010-06-28 18:19:13
我也遇到过同样的情况。
在Management Studio中，结果在20秒后出现，但是当我在visual studio中运行报告时，它锁定了系统。
在SQL profiler中，我跟踪了查询，并意识到它将我的查询转换为：
exec sp_executesql N'
....................
....................'
, @dateparameter1 = '2010-06-01 00:00:00'
, @datepamareter2 = '2010-06-02 00:00:00'
, @stringparameter=null我已经检查了执行计划，并意识到我是参数嗅探的受害者。
我已经按照here所说的那样重新组织了我的查询，现在它工作得很好。
https://stackoverflow.com/questions/2117492
复制相似问题
腾讯云开发者
