sql server2000 升级到sql server2005,一个存储过程执行时间变的很长，求救！高手请进

Question

既然有条件OrgNo，而2000下也需要10秒，说明需要统计的内容是很多的
有偿提供优化支持，呵

Answer 1

之前也有人从200升级到2005或2008，出现了性能问题，很多是由于同一个语句写法，在2000和2005中的处理方式不同，准确来说应该是sql server的内部机制可能是有变化导致的，比如select top 在2000的时候语句只需要10秒，但在2008可能需要运行2分钟。但从你的语句上来看，是标准的多表关联，应该从sql server 2000到2005，处理的机制应该变化不大。更有可能是统计信息的不准确导致的，因为在微软sql server的升级指导中，就明确指出，在升级后，最好把主要的表，更新统计信息，这样能生成适合新版本的统计信息，易于优化器生成比较好的执行计划。

Answer 2

那么具体到你这个运行慢的语句来说，你可以先试试把这几个表的统计信息，重新生成以下：update statistics Fact_Pmrelate update statistics Fact_Raw update statistics  raw

Answer 3

谢谢大家的帮助,yupeigu的很有效,从12分钟降到了7分钟.还需要继续优化.

Answer 4

try this,-- 重建索引
dbcc dbreindex('Fact_Pmrelate','',90)-- 更新统计信息
update statistics Fact_Pmrelate -- 确认SQL2005该表索引情况是否与SQL2000该表一致.-- 改为这样写法试一下..
Select f.Goodsid,r.RawId,
sum(round(PerWaste*r.Factor*(case when isnull(f.factor ,0)<=0 then 1 else 1/f.factor end), 9)) As PerWaste,
sum(round(case When p.Waste = 1 Then 0 Else p.PerWaste * r.Factor * p.Waste * (case when isnull(f.factor ,1)<=0 then 1 else 1/f.factor end)/(1 - p.Waste) End,5)) As Waste,
@userid define_by, @sysdate define_time, @userid modi_man, @sysdate modi_date
Into #temp_create_new_goods_cons
From Fact_Pmrelate (nolock) p
inner join Fact_Raw (nolock) r on p.Fmid=r.Fmid
inner join #temp_create_new_goods f on p.FPid = f.Fpid 
inner join raw (nolock) t on r.RawId=t.RawId
where p.OrgNo=@OrgNo
Group By f.Goodsid,r.RawId

Answer 5

感谢各位的指点,原因找到,是一个触发器的not in语句执行时间要6分钟,换成另一种写法,几秒钟就可以了.