sql-server-2005 - Reporting Services的性能下降，在QueryAnalyser中非常快

我们正在将SQL Server 2005与Reporting Services一起使用。

我们有许多报告，每个报告都包含一个相对简单的SQL查询-“相对”是指我们确实有一些联接，但没有比这更糟糕的了。我们不会在查询中调用任何存储过程-这不是参数嗅探的情况。

通过Reporting Services执行这些报告之一(我们称其为报告A)时，需要花费非常长的时间才能完成-大约需要数十分钟甚至几小时。在查询分析器中执行相应的SQL查询时，它会在几秒钟内完成。

从数据库返回的行数可以少至1-但是，报告从未完成。

其他报告工作正常。

在Reporting Services的ExecutionLog表中，我可以看到大多数时间都在TimeDataRetrieval中(而我们在这里谈论的是数百万秒...)-这些时间实际上是报表完成的时间。如果报表被手动中止，则TimeDataRetrieveal为零，而TimeProcessing则高得离谱。

我已经查看了Reporting Services的日志，但是一切看起来都很正常。

现在，在您开始建议“锁定”之前-好吧，我们的查询确实启用了nolock提示。

就目前而言，我已经找到了错误的极限。任何想法，见解将不胜感激。

/克里斯托弗

最佳答案

我最终剥离了查询，基本上一次删除了一条语句，直到找到罪魁祸首。查询中的一个连接使用“with(nolock index(x))”提示连接到一个不断增长的表(数百万行)中。

在查询分析器中删除索引提示可以得到与Reporting Services相同的结果-非常慢查询。这本身并不令人惊讶-但实际上，好像通过RS运行时的查询似乎没有使用提示。

然后，我尝试使用SET FORCEPLAN ON语句再次在RS中运行报表。而且...有效-执行时间现在应该是几秒钟。据我了解，FORCEPLAN选项强制SQL Server按照指示的顺序处理联接，并考虑任何提示。

在查询分析器显然考虑了提示的情况下，是否有人对为什么通过RS的查询会忽略该提示有任何见解？

关于sql-server-2005 - Reporting Services的性能下降，在QueryAnalyser中非常快，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2117492/