我有一个报告，它呈现从存储过程返回的数据。使用探查器，我可以从报告服务捕获对存储过程的调用。
报告失败，说明报告超时，但我可以从 SSMS 执行存储过程，它会在五到六秒内返回数据。
请注意，在示例测试运行中，仅将两行返回到报表进行渲染，但在存储过程中，它可能已经处理了数千甚至数百万条记录，以便整理传返回告服务的结果。
我知道存储过程可以进一步优化，但我不明白为什么 SSRS 会超时，而从 SSMS 执行似乎只需要几秒钟。
另一个问题也出现了。如果我重新创建存储过程，报告将再次开始完美呈现。这很好，只是在很短的一段时间后，报告再次开始超时。
超时的返回似乎与添加到运行报告的主表中的新数据有关。在我测试的示例中，仅插入一百条新记录就足以搞砸报告。
我认为更正确的是，报告并不是根本原因。这是存储过程导致从 SSRS 执行时超时。
一旦再次超时，我迄今为止最好的解决方法是重新创建存储过程。这似乎不是一个理想的解决方案。
该问题似乎也只发生在我们的生产环境中。我们的测试和开发平台似乎没有出现同样的问题。尽管开发和测试没有与生产相同的记录量。
最佳答案
正如您所描述的，问题似乎来自存储过程中某些部分的执行计划的变化。查看所使用的表中保留了哪些统计信息以及添加新行如何影响它们。
If you're adding a lot of rows at the end of the range of a column (think about adding autonumbers, or timestamps), the histogram for that column will become outdated rapidly. You can force an immediate update from T-SQL by executing the UPDATE STATISTICS statement.
关于sql-server - 为什么 SSRS 所基于的存储过程在几秒内返回结果时会报告超时？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/237069/