哪些因素可能导致SQL Server上的存储过程重新编译？

Question

我应该注意哪些因素会导致过多的存储过程重新编译？

将导致存储过程重新编译的代码示例将非常有用.目的是避免重新编译,如果可能的话,应该提高性能.

导致不同输出的动态SQL和变量路径(通过数据类型和/或列数)似乎可能会出现问题.这些假设是否正确？还有其他例子吗？

编辑:我找到了另一个例子.在流控制语句中创建临时表将导致重新编译.

Answer 1

有几种方法可以确保重新编译存储过程:

• 使用WITH RECOMPILE,
• 使存储过程动态(想exec())
• 标记proc以便重新编译sp_recompile.
• 更改缓存的查询计划所依赖的架构
• 调用 DBCC FREEPROCCACHE
• 在查询级别,可以使用RECOMPILE查询提示重新编译proc中的单个语句(SQL 2008).

重新编译的因素

除了上面列出的硬因素之外,是什么导致存储过程重新编译？好吧,很多东西.其中一些与上面的列表交织在一起,但我想重新呈现它们b/c它可能不是很明显.

• 插入或删除大量数据(索引和表中的数据密度通常控制查询计划)
• 重建索引(对基础对象的更改)
• 创建/删除临时表(同样,基础DML更改).
• 查询计划老化了(想想最近没用过,而sql想要清理内存使用)

这绝不是一份详尽的清单.无论您使用SQL Server多长时间,查询优化器都会发展变得惊人.但是这里有一些可能有用的资源:

• 对存储过程重新编译进行故障排除(一个老人,但是好东西)
• 重新存储存储过程
• 优化SQL Server存储过程以避免重新编译
• 执行计划缓存和重用(必读)

但等等 - 更多!

话虽如此,你的问题中的假设是重新编译总是对性能不利.事实上,经常补偿是好的.

所以你什么时候想要它重新编译？让我们看一个按姓氏搜索的proc的例子.存储过程执行' 参数嗅探 '这是一个祝福(如果它适合你)和一个诅咒(如果它对你有效).首先通过某人搜索Zebr%zerbrowski.姓氏索引意识到这是非常具体的,并且将返回,比如说,从一百万行中返回3行 - 因此构建了一个执行计划.使用proc编译为低行结果,下一次搜索是为了S%.嗯,S是你最常见的名字,在100万中匹配93,543行.