请高手指点这到底是为什么?慢下来了?

Question

再写一个存储过程，把那俩合到一起。在循环体里只调用一次EXEC试试。
exec dbo.so_xu1 @intday  
exec dbo.everyday @intday 

Answer 1

如果你的存储过程能接收两个参数，就不用循环了，，，
create proc dbo.so_xu1
    @intday datetime,
    @days int=0
as
    ...
godeclare @intday datetime, @days int
select @intday='2000-11-09', @days=datediff(d, @intday, '2007-12-01')
exec dbo.so_xu1 @intday, @days

Answer 2

相同的代码,相同的表,相同的数据量,运行这段代码会有两种情况. 
1:一开始就比较慢,一次循环要20秒左右. 
2:一开始很快,一次循环1秒左右,可10多分钟后就慢下来了. 并满足下面情况: 
a:不存在堵塞, 
-- 排除堵塞情况,
b:也没其他用户同时在操作这几张表. 
c:同时也没其它耗资源的程序在运行. 
-- 排除其它用占用资源和进程情况,每个个存储过程中都建了4个临时表,其中一个临时表是从视图取的. 
并在存储过程的最后行删除了临时表,--看看是否这几个临时表是否正常删掉,
  tempdb的变化情况,
  看看内存的使用状况,
  一般情况下,这种逐渐变慢的情况都是你在循环中没有释放掉某些资源而导致的,
  所以才会逐渐变慢,
  

Answer 3

1.插入数据量并不大，每天10条 7年 2万多条，应该不是插入数据量大的问题。
2.对于你说的两种情况可能是由于SQL的缓冲优化带来的。
3.比较赞同小熊（6楼）的，尽量合并，这样便于SQL优化，你这样相当有游标。
4.如果不能合并，则应该分段执行能你的存储过程，包括在你的两个存储过程中插入PRINT '观察点',getdate()
 来获取语句执行的时间进程，从而快速发现低点，便于针对性的优化。
 你也可以将发现的低点的区间代码贴出来，大家帮你分析。
 呵呵，测试的时候，为了节约时间，你的时间跨度可以设置小一点。

Answer 4

一开始很慢也许是第一次运行，后面都是重用看这个问题应该是tempdb数据库导致