这是我的第一篇文章,所以如果您需要澄清任何事情,请告诉我。
我的服务器详情如下: -
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年的升级版。
答案 0 :(得分:4)
这似乎是对我嗤之以鼻的参数。
你的15分钟重新索引(你需要它吗??)将导致重新编译依赖过程。有时,当发生这种情况时,将发生下一次执行时传递的参数值对于一般情况而言是次优的。您可以使用OPTIMIZE FOR来防止这种情况发生。
答案 1 :(得分:1)
这看起来像是由参数嗅探引起的。这是一个很好的解释:
SQL Garbage Collector: Parameter Sniffing & Stored Procedures Execution Plan