如何track存储过程的编译次数
有个script我们很熟悉，是用来去查找当前SQL Server中哪些存储过程变重编译的次数最多的：
--Gives you the top 25 stored procedures that have been recompiled.
select top 25 sql_text.text, sql_handle, plan_generation_num, execution_count,
dbid, objectid
into DMV_Top25_Recompile_Commands
from sys.dm_exec_query_stats a
cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where plan_generation_num >1
order by plan_generation_num desc
go
那么，这个脚本究竟是记录什么情况下的存储过程recomile呢？
我们在SQL Server上创建一个这样的store procedure：
create proc aaa
as
select plan_generation_num,* FROM DMV_Top25_Recompile_Commands where plan_generation_num > 2
然后准备好用这个脚本来返回plan_generation_num的值
select top 25 sql_text.text, sql_handle, plan_generation_num, execution_count,
dbid, objectid
from sys.dm_exec_query_stats a
cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where sql_text.text like '%aaa%'
order by plan_generation_num desc
Exec aaa之后的脚本返回结果：
这里的第六行结果集就是我们的存储过程aaa。这时的plan_generation_num值显示为1.
接下来我们mark recompile：
sp_recompile aaa
然后再次执行 exec aaa
使用脚本查询：
这里看到存储过程重编译以后，plan_generation_num的值并没有增加。
那为什么我们还会使用这样的脚本来返回重编译次数很多的存储过程呢？
接下来我们再次将存储过程mark recompile，然后直接使用脚本查询：
这时，我们发现该存储过程的plan 和text已经从DMV中移除了。看起来sp_recompile会直接将cache中缓存的执行计划和语句直接标识成不可用。因此DMV中就没有相关的记录了。
这就是说，存储过程标识重编译这种模式导致的重编译，从DMV里面是没有办法跟踪的。
那么从性能监视器的计数器 “sp recompilation/sec”里面能不能跟踪到呢？
我们反复执行：
sp_recompile aaa
exec aaa
性能监视器中一直显示为0
那么plan_generation_num的值究竟是什么含义呢？BOL中的解释很简单：
A sequence number that can be used to distinguish between instances of plans after a recompile.
中文版的含义为：可用于在重新编译后区分不同计划实例的序列号。
这里并没有说明如何去计算的序列号。我们从另一篇英文的blog中找到了更加详细的说明：
There are a lot of interesting columns in P and S, especially in S, and here I will only discuss what I have learned about plan_generation_num in S. SQL Server 2005 treats the compiled plan for a stored procedure as an array of subplans, one for each query statement. If an individual subplan needs recompilation, it does so without causing the whole plan to recompile. In doing so, SQL Server increments the plan_generation_num on the subplan record to be 1 + MAX(plan_generation_num for all subplans). The general distribution of plan_generation_num among all subplans for a given plan is such that it has multiple of 1's and distinct numbers > 1. That is because all subplans start with 1 as their plan_generation_num. Appendix A is the query for learning plan_generation_num.
http://lfsean.blogspot.com/2008/02/understanding-sql-plangenerationnum.html
这部分说明简单的来说，就是只要存储过程中有一条语句发生重编译，这个plan_generation_num值就会+1.这里并没有说是整个存储过程重编译的时候，这个值会+1.
接下来我们修改测试存储过程aaa：
Alter TABLE aaa_table(
[text] [nvarchar](max) NULL,
[sql_handle] [varbinary](64) NOT NULL,
[plan_generation_num] [bigint] NOT NULL,
[execution_count] [bigint] NOT NULL,
[dbid] [smallint] NULL,
[objectid] [int] NULL
) ON [PRIMARY]
insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2
insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2
insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2
insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2
insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2
然后我们执行存储过程，收集profiler trace，同时继续监控性能监视器
开始重新执行存储过程aaa
这里我们可以看到sp recompilation/sec立刻变成了7。
Profiler trace中可以看到每条insert语句上都触发了一个sp:recompile
脚本的查询结果：
可以看到plan_generation_num的值增加到6了。
为什么这样写存储过程会导致重编译？http://support.microsoft.com/kb/243586 这篇文章中列举了多种会导致存储过程重编译的情况：
aaa这个存储过程符合这个条件：
The procedure interleaves Data Definition Language (DDL) and Data Manipulation Language (DML) operations.
因此我们的结论是，使用这个脚本去查询重编译次数高的存储过程是没有错的，但是这个脚本并不包含由于sp_recompile已经定义存储过程时使用了with recompile的选项而导致的存储过程重编译的情况。