那是因为第一次查询是从磁盘取的数据,查询完成后,数据放在了缓存中,第二次查询直接从内存中取的数据,所以第一次比较卡,第二次比较快,重启后依旧你执行sql前,执行set statistics io on打开IO,看看物理读就知道了再不是第一次执行查询完成后,执行 dbcc dropcleanbuffers,清楚缓存数据,第二次也是会“很卡”

解决方案 »

  1.   

    你这个例子比较容易让我联想到你的执行计划被清空,重启之后,又要重新编译,编译是非常耗资源的操作。如果第一次非常慢,那你要看看是否查询很复杂,导致cpu过高。这也是为什么SQLServer甚至其他的数据库产品,都要“吃”那么大内存的原因,绝大部分内存用于缓存计划,使得下一次执行的时候可以尽可能避免编译。
      

  2.   

    楼主你理解错意思了,第一次查询完执行 dbcc dropcleanbuffers清除缓存,然后在执行第二次查询的意思是给你解释下为什么出现第一次查询会卡第二次又正常这个情况。然后你要解决为什么第一次会卡的情况,你要进行判断为什么第一次会卡,说明你需要对查询语句、数据库进行优化