我有一个维护计划,每天早上在工作时间之前在我的SQL Server 2008服务器上运行。几年前它已经实施,以帮助解决一些性能问题。我看到的问题是,在重建索引完成后,其中一个数据库中存在一个存储过程,从运行9秒到运行需要7分钟。
我发现修复它的解决方案是打开SQL Management Studio并运行:
EXEC sp_recompile N'stored_proc_name';
EXEC stored_prod_name @userId=579
运行之后,SP自行修复并在9秒内恢复运行。
我已经尝试了几种不同的路径来实现自动化,但只有当我从我的计算机通过管理工作室运行它时它才会起作用。我试图将它包装在一个C#可执行文件中,该可执行文件在重建索引作业完成后运行几分钟,但是没有用。我还尝试创建一个SQL作业,以便在重建索引作业完成后在服务器上运行它,但这也不起作用。它必须从管理工作室运行。
所以,有两个问题:
谢谢, 麦克
答案 0 :(得分:0)
这听起来像标准参数嗅探/基于参数的查询计划缓存。这里的诀窍通常是使用OPTIMIZE FOR
/ UNKNOWN
提示 - 用于导致问题的特定参数,或者仅用于所有参数。这使得具有偏差分布的参数值不太可能对系统的其他值产生负面影响。更极端的选项(在使用命令文本时更有用,在使用存储过程时不太有用)是将值直接嵌入到TSQL中而不是使用参数。但是......这有影响,应该谨慎使用。
在您的情况下,我怀疑添加:
OPTION (OPTIMIZE FOR (@userId UNKNOWN))
到查询结尾将修复它。