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

疯狂熊猫人 2015-04-13 05:45:01

今天在进行程序优化的时候，将每次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会出现如此巨大的差别呢？

...全文

577 11 打赏收藏转发到动态举报

写回复

用AI写文章

11 条回复

切换为时间正序

请发表友善的回复…

发表回复

JDK9 2015-10-22

打赏
举报

牛人还是多，学习了

还在加载中灬 2015-04-14

打赏
举报

我想如果能看下你的执行语句及相应的执行计划，应该能比较清楚的明白是为什么了在这之前，我想很可能的和#2楼的说的情况一样，而INSERT语句一般只有一种可能的执行，同UPDATE的情况不一样，SQLSERVER不会再寻求更好的计划

疯狂熊猫人 2015-04-14

打赏
举报

今天在进行程序优化的时候，将每次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会出现如此巨大的差别呢？各位大神能不能仔细看了问题再回复啊？我相信我描述的已经很明白了。各位不要避重就轻啊！

疯狂熊猫人 2015-04-14

打赏
举报

引用 6 楼 ky_min 的回复:

9ms和11ms是同一个数量级的，这点差距说明不了问题

我的疑问是sql语句批量update会比调用存储过程批量update慢很多，但是insert却没有出现这个问题。列出的9ms与11ms只是说明insert的执行效率与使用存储过程关系不大。

还在加载中灬 2015-04-14

打赏
举报

9ms和11ms是同一个数量级的，这点差距说明不了问题

Tiger_Zhao 2015-04-14

打赏
举报

因为存在缓存和“执行计划重用”的优化，实际上循环调用相同的语句，很难明确什么时候会重编译执行计划。
不过单纯比较直接使用update语句和存储过程，可以说最明显的差别是是否需要编译。
如果为了比较大批量的循环执行，只能实测看SQL Server的优化效果如何了。

疯狂熊猫人 2015-04-14

打赏
举报

引用 2 楼 Tiger_Zhao 的回复:

直接使用update语句，每次调用都要先编译语句再执行。而存储过程是已编译好的计划，无论调用多少次都是直接执行无需再编译。

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

疯狂熊猫人 2015-04-14

打赏
举报

引用 2 楼 Tiger_Zhao 的回复:

直接使用update语句，每次调用都要先编译语句再执行。而存储过程是已编译好的计划，无论调用多少次都是直接执行无需再编译。

如何解释直接使用insert语言会比把insert语句写在存储过程中调用要快呢？

Tiger_Zhao 2015-04-14

打赏
举报

直接使用update语句，每次调用都要先编译语句再执行。
而存储过程是已编译好的计划，无论调用多少次都是直接执行无需再编译。

卖水果的net 版主 2015-04-14

打赏
举报

你 java 程序，在执行 update 时，是不是与数据有交互？如果有的话，肯定要慢下来。

Mr_Nice 2015-04-14

打赏
举报

引用 8 楼 crazypandariy 的回复:

今天在进行程序优化的时候，将每次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看一下执行计划，毕竟这个是具体语句不同可观察的部分。也比较直接。

内容覆盖大模型基础原理、预训练微调、分布式训练优化、RAG系统搭建、Agent开发、推理部署、多模态落地、prompt工程、安全合规、垂直行业定制、MLOps全生命周期管理等全链路技术点，兼具理论深度与实战可操作性，助力开发者系统掌握大模型从技术研发到商业化落地的全流程核心能力。

内容概要：本文围绕天空图像与光伏发电预测展开研究，结合Python编程实现相关算法，旨在利用天空图像数据对光伏发电功率进行高效、准确的预测。研究内容涵盖图像采集与预处理、云层运动分析、辐照度估算以及光伏出力预测模型的构建，通过机器学习或深度学习方法建立从视觉信息到发电量之间的映射关系，提升光伏发电系统的可观测性与调度能力。文中提供了完整的代码实现流程，便于读者复现和优化算法。; 适合人群：具备一定Python编程基础和机器学习知识，从事新能源、电力系统预测或图像处理方向的科研人员及工程技术人员，尤其适合研究生及以上学历或工作1-3年的相关领域从业者。; 使用场景及目标：①应用于太阳能电站的短期发电功率预测，提高电网调度精度与可再生能源消纳能力；②作为科研项目的技术参考，支撑基于视觉的环境感知与能源预测交叉领域的算法开发与验证。; 阅读建议：建议读者结合实际气象数据与图像样本进行代码调试与模型训练，重点关注图像特征提取与时间序列预测模块的衔接，并尝试引入更先进的网络结构（如Transformer、CNN-LSTM等）以进一步提升预测性能。