今天一个生成10w条数据的存储过程执行了95s,但是单独执行SQL语句只需要28s,查资料后发现原来这是存储过程的机制导致的，也就是传说中的参数嗅探
网上的一段话：
（1）可能是发生了参数嗅探，第一次赋给存储过程的输入参数，会为该存储过程生成一个基于输入参数的执行计划，因此如果第一次输入的参数不具有代表性（例如大部分查询输入的参数都是A值，但第一次执行存储过程时输入的是B值），就有可能比即席查询慢，尽管即席查询需要重新编译执行计划，但选择了更有效率的计划。
尝试使用和即席查询一样的参数，来执行存储过程，然后对比一下两者的执行计划。
（2）通常存储过程最上面有自带的set设置，如set ansi_nulls on，而即席查询通常没有包含，这些set设置也会影响执行计划。
尝试在即席查询中添加上，与存储过程一样的set设置，然后再对比一下执行计划。
把存储过程的参数赋值给了存储过程中自定义的变量，整个存储过程中使用这个变量来代替参数，执行速度就和执行SQL一样了
一篇介绍参数嗅探的好文：http://www.cnblogs.com/lyhabc/archive/2013/03/02/2941144.html