关于存储过程的效率问题

[chenyu112]

发现一个比较不能理解的问题：
存储过程在运行一段时间后，就会非常的慢。在SQL2005中单独执行这一个存储过程也是很慢的
但是如果修改一下此存储过程（内容不变），此时再执行就会很快，大约能节省一半的时间
不知道为什么会出现这种情况？原理？如何避免？
数据库是SQL Server2005

[SQL77]

重新编译了一下执行计划,可能

[dawugui]

[Quote=引用楼主 chenyu112 的回复:]
发现一个比较不能理解的问题：
存储过程在运行一段时间后，就会非常的慢。在SQL2005中单独执行这一个存储过程也是很慢的
但是如果修改一下此存储过程（内容不变），此时再执行就会很快，大约能节省一半的时间
不知道为什么会出现这种情况？原理？如何避免？
数据库是SQL Server2005
[/Quote]
1.重建或重新编译此存储过程
2.将存储过程中涉及到的表,其索引重建一下.

[--小F--]

查看执行计划 看看主要消耗在什么地方了..

[htl258_Tony]

应该没有你说的那种情况。在某时间段内，运行第一次会比较慢，之后再运行就比较快这是正常现象，第二次运行时还能用到第一次的一些缓存。

[水族杰纶]

如果存储过程不经常调用

create proc pro_name
with recompile
as
.....

[--小F--]

查看一下索引碎片 如果超过25&%和、建议重新建立索引

[--小F--]

查看一下索引碎片 如果超过25%和、建议重新建立索引

[水族杰纶]

如果存储过程不经常调用
编译之后常驻内存 这样也会耗费内存资源
降低整个系统效率

[水族杰纶]

但是如果修改一下此存储过程（内容不变），此时再执行就会很快，大约能节省一半的时间

应该不是索引,碎片的缘故

[chenyu112]

谢谢各位，我查一下碎片

数据库的结构没有发生过变化
只要存储过程执行一段时间后就会很慢，重新执行一下又就可以了
我们经常出现这种情况

[SQL77]

[Quote=引用 9 楼 wufeng4552 的回复:]
但是如果修改一下此存储过程（内容不变），此时再执行就会很快，大约能节省一半的时间

应该不是索引,碎片的缘故
[/Quote]
同意,可能执行计划占大部分原因

[水族杰纶]

[Quote=引用 10 楼 chenyu112 的回复:]
谢谢各位，我查一下碎片

数据库的结构没有发生过变化
只要存储过程执行一段时间后就会很慢，重新执行一下又就可以了
我们经常出现这种情况
[/Quote]
--try
--修改存储过程 加上with recompile参数

alter proc proc_name
...
with recompile
as

[Yang_]

可能，搂主的服务器内存太多了
存储过程的执行计划被缓存，随后由于数据的变化，原有的执行计划已经不是最优的，但是由于缓存未被替换，还是按照缓存的执行计划执行，速度就很慢，重新编译或者重建下存储过程则解决。

[999朵玫瑰]

高手好多哦。学习了