同一存储过程的不同执行计划

你的统计数据很可能已经过时了。如果数据相同,请在两台服务器上重新计算统计信息并重新编译。然后您将看到相同的查询计划。

另外,再次检查索引是否相同。

最有可能的统计数字。

一些想法:

如果是,您是否使用相同的填充因子和统计样本比率?

您是否定期将数据库恢复到测试中,使其100%类似于生产?

如果您知道为什么一个查询比另一个查询耗时更长?你能发布更多的细节吗?

在这种情况下,由于表中的数据和/或统计数据,执行计划可能会有所不同。即使在启用自动更新统计信息的情况下,统计信息也可能过时(特别是在非常大的表中) 您可能会发现优化器估计表没有那么大,并选择了表扫描或类似的方式。

下面是一个关于如何缓存错误查询计划的简单示例:

create proc spTest
    @id int 
as 
select * from sysobjects where @id is null or id = id 

go 

exec spTest null
-- As expected its a clustered index scan

go

exec spTest 1
-- OH no its a clustered index scan 

尝试在存储过程之外的生产服务器上运行Sql in QA,以确定您的统计信息是否过期或生产中是否缺少神秘索引。

我认为参数嗅探行为在2005年和2008年之间有所不同,因此这可能不起作用。

解决办法是重新计算统计数据。我忽略了这一点,因为通常我们都有计划的任务来完成所有这些,但是出于某种原因,管理员没有把一个放在这个服务器上,Doh。

总结所有帖子:

• 检查设置是否相同
  • 索引
  • 桌子尺寸
  • 还原数据库
• • 如果查询在存储过程外部运行相同的查询,则它不是执行计划
  • 如果sp_不同,请重新编译
  • 参数嗅探