我应该注意哪些因素会导致过多的存储过程重新编译？
导致存储过程重新编译的代码示例将很有用。目的是避免可能会提高性能的重新编译。
导致不同输出(按数据类型和/或列数)的动态SQL和变量路径似乎可能会带来问题。假设是否正确？还有其他例子吗？
编辑:我确实找到了另一个例子。在流控制语句中创建临时表将导致重新编译。
最佳答案
有几种方法可以确保重新编译存储过程:
WITH RECOMPILE，exec())sp_recompile重新编译的proc。 DBCC FREEPROCCACHE 重新编译的因素
除了上面列出的硬性因素之外，是什么导致存储过程重新编译？好吧，很多事情。其中一些与上面的列表交织在一起，但是我想用b/c重新呈现它们，这可能并不明显。
这绝不是详尽的 list 。无论您使用SQL Server已有多长时间，查询优化器都会不断发展和令人惊讶。但是这里有一些可能有用的资源:
但请等待-还有更多!
话虽如此，您的问题的前提是重新编译始终对性能不利。实际上，经常重新整理是好的。
那么您什么时候要重新编译呢？让我们看一个按姓氏搜索的proc示例。存储过程执行“parameter sniffing”，这是一种祝福(如果它对您有用)和一个诅咒(如果它对您不利)。首先通过，有人在
Zebr%上搜索zerbrowski。姓氏索引意识到这是非常特定的，并且可以返回(假设从一百万个记录中减去3行)，因此构建了一个执行计划。在将proc编译为低行结果的情况下，下一个搜索是S%。好吧，S是您最常用的名字，它与100万个行中的93,543行匹配。关于sql-server - 哪些因素可以导致SQL Server上的存储过程重新编译？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9054100/