sql server查询巨慢解决实例

最新推荐文章于 2025-10-10 11:06:06 发布

原创最新推荐文章于 2025-10-10 11:06:06 发布 · 2.6k 阅读

3 ·

CC 4.0 BY-SA版权

数据库专栏收录该内容

6 篇文章

订阅专栏

本文通过一个具体的案例，展示了如何诊断并解决SQL查询性能问题。通过对执行计划的分析及统计数据的更新，成功将查询时间从十分钟缩短到两秒以内。

这是在计算某个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性能严重降低所致。