我们将 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 中相同的结果 - a 非常慢查询。这本身并不奇怪 - 但确实看起来好像通过 RS 运行时的查询没有使用提示。
然后我尝试使用 SET FORCEPLAN ON 语句再次在 RS 中运行报告。而且......它起作用了 - 现在执行时间应该是几秒钟。据我了解， FORCEPLAN 选项强制 SQL Server 按照指示的顺序处理连接，并考虑任何提示。
当查询分析器显然将其考虑在内时，是否有人对为什么通过 RS 的查询会忽略该提示有任何见解？
关于sql-server-2005 - Reporting Services 的性能很慢，在 QueryAnalyser 中非常快，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2117492/