Sproc性能随着时间的推移而降低

时间:2010-09-27 12:47:19

标签: sql sql-server tsql

这是我的第一篇文章,所以如果您需要澄清任何事情,请告诉我。

我的服务器详情如下: - Windows 2008数据中心版
SQL 2008标准版(10.0.1600)
12GB拉杆
四核单处理器机

问题
我有一个运行的存储过程,当我刚启动SQL时,运行大约需要1/10秒。经过一段时间后,运行相同的查询大约需要3秒钟。

我最初认为它是引起问题的索引,但如果我制作了一个精确的sproc副本并运行该复制版本,那么该查询现在只需要1/10秒再次,原始的仍需要3秒

我现在假设它与缓存的sproc的执行计划有关,当sproc再次运行时,它会破坏执行计划。

到目前为止我尝试过的事情
我目前有一个维护计划,每15分钟运行一次,重新索引一个小表,由于某种原因,我的sprocs执行的时间回落到正常水平,但随后时间突然再次恢复。

创建了一个sproc的副本来测试它,并且它在1/10秒运行,而原始的仍然需要很长时间。

运行“update stats”sproc以确保所有统计信息都是最新的。

Ran SQL查询分析器查看它是否对应该在表上的其他索引提出任何建议,最终提出一些建议,将我的索引和db大小增加到70gb以上,性能提升可忽略不计。

需要注意的其他信息
db在同一实例中分布在两个dbs上,一个包含产品信息,另一个包含客户信息。

其中一个连接表是1.3亿行。

db是从2005年到2008年的升级版。

2 个答案:

答案 0 :(得分:4)

这似乎是对我嗤之以鼻的参数。

你的15分钟重新索引(你需要它吗??)将导致重新编译依赖过程。有时,当发生这种情况时,将发生下一次执行时传递的参数值对于一般情况而言是次优的。您可以使用OPTIMIZE FOR来防止这种情况发生。

答案 1 :(得分:1)

这看起来像是由参数嗅探引起的。这是一个很好的解释:

I Smell a Parameter!

SQL Garbage Collector: Parameter Sniffing & Stored Procedures Execution Plan