重建索引任务破坏了存储过程的复杂性

本文关键字：存储过程 复杂性 坏了 索引 任务 重建 | 更新日期: 2023-09-27 18:08:01

我有一个维护计划，每天早上在工作时间之前在我的SQL Server 2008服务器上运行。它是在几年前实施的，以帮助解决一些性能问题。我看到的问题是，在重建索引完成后，其中一个数据库中的存储过程将从运行9秒变为运行7分钟。

我找到的解决方案是打开SQL管理工作室并运行:

EXEC sp_recompile N'stored_proc_name';
EXEC stored_prod_name @userId=579

在我运行之后，SP自我修复并在9秒内恢复运行。

我已经尝试了几个不同的路径来自动化这个，但是只有当我在我的电脑上通过管理工作室运行它才会起作用。我试图将其封装在一个小小的c#可执行文件中，在重建索引作业完成后运行几分钟，但这不起作用。我还尝试创建一个SQL作业，以便在重建索引作业完成后在服务器上运行它，但这也不起作用。它必须从管理工作室运行。

那么，两个问题:

  1. 如何阻止重建索引打破我的SPs，或者，
  2. 关于如何或为什么我的快速修复只会在一个非常具体的情况下工作的想法?

谢谢,迈克

重建索引任务破坏了存储过程的复杂性

这听起来像是标准的参数嗅探/基于参数的查询计划缓存。这里的技巧通常是使用OPTIMIZE FOR/UNKNOWN提示——要么针对导致问题的特定参数，要么针对所有参数。这使得具有偏置分布的参数值对系统的其他值产生负面影响的可能性大大降低。一个更极端的选项(在使用命令文本时更有用，但在使用存储过程时不太有用)是将值直接嵌入到TSQL中，而不是使用参数。这个…有影响，但应谨慎使用。

在你的情况下，我怀疑添加:

OPTION (OPTIMIZE FOR (@userId UNKNOWN))
相关文章：