update语句直接执行与写在存储过程中执行性能区别很大，为什么呢

update语句直接执行与写在存储过程中执行性能差别很大，为什么呢？
今天在进行程序优化的时候，将每次update修改为了批量update，使用的是Java JDBC批量更新。
10万条数据，每次批量更新50条：
update：
1、直接使用update语句进行batch update，平均每次耗时100ms
2、将update语句写到存储过程中，调用存储过程batch update，平均每次11ms

insert：
1、直接使用update语句进行batch insert，平均每次耗时9ms
2、将insert写入存储过程batch insert，平均每次耗时11ms

为什么update会出现如此巨大的差别呢？
------解决思路----------------------

引用:

今天在进行程序优化的时候，将每次update修改为了批量update，使用的是Java JDBC批量更新。
10万条数据，每次批量更新50条：
update：
1、直接使用sql语句进行batch update，平均每次耗时100ms
2、将update语句写到存储过程中，调用存储过程batch update，平均每次11ms

insert：
1、直接使用sql语句进行batch insert，平均每次耗时9ms
2、将insert写入存储过程batch insert，平均每次耗时11ms

为什么update会出现如此巨大的差别呢？
各位大神能不能仔细看了问题再回复啊？我相信我描述的已经很明白了。各位不要避重就轻啊！

lz 这个问题挺早就有相关的讨论。实际上就是存储过程编译以及查找对应执行计划的优化过程的理解。

update 的差异可以理解为存储过程，“第一次”被调用后，缓存下来的执行计划复用而带来的时间优势（节约了编译等时间）

insert 的类似，则是参数嗅探的问题。也就是说，sql server 在执行存储过程中的语句时，对应参数进行嗅探，会产生不同的选择性估计值，根据其内部的优化方案，进行执行计划的选择。最明显一个例子就是 @date 一个时间变量。

lz可以查看一下参数嗅探这部分内容。

最后，还是建议lz看一下执行计划，毕竟这个是具体语句不同可观察的部分。也比较直接。