为什么计算执行计划需要这么长时间？

我们的一位客户刚刚升级到新服务器。

对于特定的存储过程，首次执行该过程要花费三分钟以上的时间。随后的运行少于1秒。

这使我相信，最初的三分钟主要用于计算执行计划。然后，后续运行只需使用缓存的计划即可立即运行。

在我们的测试数据库上，大约需要5秒钟来计算同一步骤的计划。

我看不出计划本身有什么可怕的-尽管我不认为计划的相关性，因为计划显示了运行查询所花费的时间，而不是计算自身。

该服务器是16核，具有24 GB内存。不会发生繁重的CPU或内存负载。

是什么会导致仅在特定数据库上如此缓慢的计算？

我可以采取什么步骤找到问题的原因？

编辑

因此，我设法访问服务器并使用SET SHOWPLAN_XML ON运行查询。

我可以确认查询的CompileTime占用了查询执行时间的99％。该StatementOptmEarlyAbortReason是“超时”，我们与他们的数据库副本的原因是MemoryLimitExceeded测试数据库。

sql-server sql-server-2008 execution-plan

— 孟格斯·庞
source

您确定它的计划编译需要很长时间，而不仅仅是从磁盘读取数据到缓存中？

— Mark Storey-Smith'2

编译时间确实显示在计划XML本身中。您是否确定这肯定是编译时间，而不是其他时间，例如同步自动更新统计信息？您正在使用哪个版本的SQL Server？

— 马丁·史密斯

@ MarkStorey-Smith好吧，我对任何事情都不十分确定。我确实知道，运行DBCC FREEPROCCACHE（仅清除该计划缓存）将使下一个查询时间最多恢复3分钟。

— 蒙格斯·庞

@MartinSmith是的，非常有用，我一直在使用视觉查询计划。是的，编译时间大约是查询的整个执行时间。我们正在使用SQL Server 2008 R2。

— 孟格斯·庞

@MongusPong-如果仅创建统计信息的生产数据库副本，则可以在测试环境中重现此副本吗？该计划说明StatementOptmEarlyAbortReason什么？

— 马丁·史密斯

我不愿回答自己的问题，特别是因为我在别人的帮助下制定了解决方案，但这很有意义。

该问题是由于数据库中的一些统计信息不正确所致。查看执行计划，优化器期望从查询中返回11.5tb的数据。实际上是接收87kb。我现在知道，返回的预期行与实际行之间存在巨大的不匹配，这表明统计信息已过时。

只需运行

exec sp_updatestats

强制数据库更新所有表的统计信息。

这使查询执行时间从3分钟减少到6秒。大家都是赢家！

感谢所有帮助人员。：0）

— 孟格斯·庞
source