这是在计算某个KPI指标的时候发现的,下面是摘录的统计代码,就是这段代码巨慢,10分钟也没出结果:
select dateid,EID,DID,y.Kpiid,y.[Property],Val=sum(JFJe-DFJe),d.start,d.[end]
into #Val_1
from KPI.YWData y --with(index(OpTime_IDX))
join #Dateident d on y.OPtime>=d.Start and y.OpTime<d.[End]
join #KPIID k on y.KPIID=k.KPIID
group by d.dateid,y.KPIID,y.[Property],EID,DID,d.Start,d.[end]
代码实际运行时中,#Dateident一条记录,#KPIID 有 15000条记录,KPI.YWData是业务数据,经过条件OPtime>=d.Start and OpTime<d.[End]过滤后,约有670000条记录,以我对客户数据库性能的了解,这个数据量最多2秒应该出结果,到底什么原因呢?
看起来这段脚本没有太多的优化项,KPI.YwData中时间字段OpTime已经加有索引,而且是聚簇索引,经测试,发现:
select sum(JFJe-DFJe)
into #Val_1
from KPI.YWData y --with(index(OpTime_IDX))
join #Dateident d on y.OPtime>=d.Start and y.OpTime<d.[End]
join #KPIID k on y.KPIID=k.KPIID
结果秒出,看起来和Group by 有关,于是加上Group by d.dateid,又一次变得巨慢,百思不得其解,按道理,group by是在筛选后的数据上做汇总,数据量未变,而且,#Dateident仅有一条数据,意味着上面两次查询返回结果也一样,不禁陷入长思。
为了查找原因,写了如下两个统计语句,并观察执行计划:
SELECT sum(YPID) FROM DrugMaterial.DMItem
SELECT sum(YPID)
FROM DrugMaterial.DMItem d
join(select A=1) as t on 1=1
group by A
两条语句可以说无差别,但是执行计划却不一样:
根据以往的经验,执行计划依赖统计结果,难道是统计结果有问题,于是,执行
update statistics KPI.YWData
再执行原来的语句,2秒不到,至此,性能问题解决,现在分析,应该是统计结果有问题导致sql server制定了不合适的执行计划,导致Nested Loops性能严重降低所致。