在.net开发过程中,遇到一个奇怪的问题:
    在sql server2005中一个实现执行复杂联合查询的存储过程;在查询分析器中直接执行速度很快;但是通过c#程序调用或者VB6.0程序调用需要相当长的、完全非正常的时间才能返回结果。
   还有那种使用临时表较多的存储过程也会出现与上面类似的情况。
   如果将存储过程重新Alter一下之后程序再调用,则执行速度恢复正常;但是多次运行之后又会出现异常。
   
   不知道有没有人碰到过类似的问题,望能给出一个解答;到底是c#程序的问题还是sql server2005的问题?

解决方案 »

  1.   

    之前有碰到过。情况和LZ的一样。后面检查是调用的代码有问题。LZ仔细检查你的代码吧。
      

  2.   

    在c#中调用,查询时间的起始与截止取值是否只包含数据库连接和查询,还是把数据的页面加载也算进去,如果是后者,则时间统计是不准确的,如果显示的记录数较多时差别很大。还有可能跟sql 缓存有关系,在查询分析器中执行,第二次以及以后的查询时间与第一次的查询时间差别比较大,第一次查询耗时较多
      

  3.   

    To step_123 :
      查询的时间是计算从程序发送SQL到返回结果这一段的;而且基本上排除数据缓存的影响,因为时间差距是30秒与最离谱的情形下要20分钟的区别。
       而且有时快,有时慢;经过初步观察好像数据库访问少的时候会快,访问的人一多就慢了。我们数据库常态数据库连接大概600个,DB服务器2CPU,4GHZ,4G内存,带宽1G。To dolphin683 :
      目前发现有此问题的存储过程中没有用到游标,有几个是用到多个临时表;一个就是嵌套多层的查询。TO xray2005 :
      代码应该也没有问题,我就写了一个简单的测试程序就是应用ADO.NET执行SQL语句而已。   现在的问题是,为什么查询分析器中无论怎么样执行都不会出现直接用程序调用那么慢的情况,而用程序调用就常常很慢。
       
      

  4.   

    我也是,郁闷了,alter一下还真有用
      

  5.   

    看来是这个原因:当存储过程涉及的对象结构调整, 或者相关的数据产生了很大变化, 这可能导致原来的计划不适合当前的现状(执行计划过期), 这种情况下应该重新编译存储过程(可以通过 sp_recompile来标记要重新编译的存储过程) 谢谢! 哈哈,结帖后再来总结一下:
    使用了 exec sp_recompile @objname='存储过程的名字',然后又执行了一次后,在程序中运行,即可!恢复正常。