这种行为，被称为重编译（recompile）。下面是比较常见的会发生重编译的情形：
1、当指令或者批处理所涉及的任何一个对象（表格或者视图）发生了架构（schema）变化
例如，在表或者视图上添加或删除了一个字段，添加或者删除了一个索引，在表上添加或者删除了一个约束条件（constraints）等。
定义发生了变化，原来的执行计划就不一定正确了，当然要重编译
2、运行过sp_recompile
当用户在某个存储过程或者触发器上运行过sp_recompile后，下一次运行他们就会发生一次重编译。
如果用户在某个表或者视图上运行了sp_recompile，那么所有引用到这张表（或者视图）的存储过程在下一次运行前，都要做重编译
3、有些动作会清除内存里的所有执行计划，迫使大家都要做重编译
例如，下列动作会清除整个SQLSERVER服务器缓存的所有执行计划：
(1)Detach一个数据库
(2)对数据库做了升级，在新的服务器上，会发生执行计划清空
(3)运行了DBCC freeproccache
(4)运行了reconfigure语句
(5)运行了alter database..collate语句修改了某个数据库的字符集（collation）
下列动作会清除SQLSERVER服务器缓存的某个数据库的执行计划：
DBCC FLUSHPROCINDB
清除SQL Server 2000服务器内存中的某个数据库的存储过程缓存内容
DECLARE @a INT
SELECT @a=DB_ID(‘gposdb’)
DBCC flushprocindb(@a)ALTER DATABASE …MODIFY NAME语句
ALTER DATABASE …SET ONLINE语句
ALTER DATABASE…SET OFFLINE语句
ALTER DATABASE…SET EMERGENCY语句
DROP DATABASE 语句
当一个数据库自动关闭时
DBCC CHECKDB语句结束时
4、当下面这些SET 开关值变化后，先前的那些执行计划都不能重用
ansi_null_dflt_off,
ansi_null_dflt_on,
ansi_nulls,
_ansi_padding
ansi_warnings,
arithabort,
concat_null_yields_null,
datefirst,dateformat,
forceplan,
language,
no_browsetable,
numeric_roundabort,
quoted_identifier
这是因为这些SET开关会影响语句的执行的行为，甚至带来不同的结果。他们发生变化了，SQLSERVER就要根据新的设置重做执行计划
5、当表格或者视图上的统计信息发生变化后
当统计信息被手动更新后，或者SQLSERVER发现某个统计信息需要自动更新时，SQLSERVER会对所涉及的语句都做重编译
需要说明的是，在SQLSERVER里，执行计划重用并不一定是一件好事，而编译/重编译也不一定是一件坏事。
计划重用可以帮助SQLSERVER节省编译时间，对降低CPU使用率和减少阻塞都有好处，但是缺点是每次重用的计划并不一定是最合适的计划。
参数嗅探parameter sniffing就是典型的计划重用带来的负效应。编译和重编译当然能给当前运行的语句带来尽可能准确执行计划， 但是对于经常运行的语句，尤其是一些执行速度比较快的语句，可能其编译时间占最后总时间的相当大比例。这对资源来讲是一个很大的浪费
