使用MSSQL 2005
今天我被叫来看看一个存储过程，从我们的程序使用开始执行缓慢。 大约在几秒钟的时间里，它立即执行。 我运行了SQL Server Profiler，它使用了1000多个CPU和超过400,000个读取。 我将SQL Server Profiler中的Exec行复制到SQL Management Studio中查看执行计划。 存储过程立即执行并返回正确的结果。 执行计划看起来是正确的，没有明显的错误。 我试着从我们的程序中多次运行它，看看它是不是被caching了，而且在执行计划被确定的时候，我只是看到了第一次运行放缓，但是在每次运行2-3秒时是一致的。
对于踢我然后运行DBCC FreeProcCache只是为了看看这是否会使我从SQLpipe理运行的运行速度变慢。 从pipe理工作室运行存储过程，它仍然立即运行。 然后，我再次从程序中运行程序，运行Profiler，它也立即运行。 分析器显示CPU已经下降到0，Reads已经下降到了40.现在似乎一直保持快速。
为什么要运行DBCC FreeProcCache加速存储过程如此激烈？
简短的答案：参数嗅探。
长的答案是：当你第一次运行一个存储过程时，查询优化器将查看传递给它的参数以及有关被查询对象的元数据。 如果元数据随时间显着变化（例如统计信息直方图发生变化），或者初始参数不代表典型调用，则优化器caching的计划可能会变得不理想。 通过做一个freeproccache，你摆脱了“坏”的计划，并强制查询优化器再次运行。
如果你能找出哪个存储过程是有问题的subprocess，你可以在程序的定义中添加“with recompile”，它不会caching该进程的计划。 如果你可以在程序中find导致问题的语句，你可以添加“选项（重新编译）”，只有当程序运行时这个语句才会被重新编译。