我有一个最近变得不可预测的 SQL Server 2005，我正在摸索为什么。在几秒钟内执行的查询正在更改计划并花费几分钟（在全表扫描或索引假脱机中花费时间）。现在第一个也是最明显的事情是，统计数据已经过时导致优化器感到困惑，但我相信事实并非如此 - 首先是因为基础数据没有显着变化（例如，在一年的数据之上添加一天的数据已经在表中），其次是因为自动创建统计和自动更新统计都是真的。然而，优化器越来越困惑；在 Tuning Advisor 中运行 SQL 给了我很多CREATE STATISTICS似乎可以修复它的多列语句（直到 SQL 的下一个错误行为）。
我可以用来解决根本原因的任何策略想法吗？为什么“正常”统计数据还不够？
我们的一位客户刚刚升级到新服务器。
对于一个特定的存储过程，第一次执行它需要三分钟的时间来运行。后续运行不到 1 秒。
这让我相信最初的三分钟主要用于计算执行计划。后续运行只需使用缓存的计划并立即运行。
在我们的测试数据库上，计算相同程序的计划大约需要 5 秒。
我在计划本身中没有看到任何可怕的东西 - 尽管我不认为它是相关的，因为计划显示了运行查询需要多长时间，而不是计算本身。
该服务器为 16 核，24 GB 内存。不会发生沉重的 CPU 或内存负载。
是什么导致仅在特定数据库上计算如此缓慢？
我可以采取哪些步骤来找出问题的原因？
编辑
所以我设法访问服务器并使用SET SHOWPLAN_XML ON运行查询。
我可以确认查询的 CompileTime 占用了查询执行时间的 99%。该StatementOptmEarlyAbortReason是“超时”，我们与他们的数据库副本的原因是MemoryLimitExceeded测试数据库。