mybatisplus批量insert性能_记⼀次接⼝性能优化实践总结：
优化接⼝性能的⼋个建议
前⾔
最近对外接⼝偶现504超时问题，原因是代码执⾏时间过长，超过nginx配置的15秒，然后真实弹搞了⼀次接⼝性能优化。在这⾥结合优化过程，总结了接⼝优化的⼋个要点，希望对⼤家有帮助呀~
数据量⽐较⼤，批量操作数据⼊库
耗时操作考虑异步处理
恰当使⽤缓存
优化程序逻辑、代码
SQL优化
压缩传输内容
考虑使⽤⽂件/MQ等其他⽅式暂存，异步再落地DB
跟产品讨论需求最恰当，最舒服的实现⽅式
嘻嘻，先看⼀下我们对外转账接⼝的⼤概流程吧
1.数据量⽐较⼤，批量操作数据⼊库
优化前：
1. //for循环单笔⼊库
2. for(TransDetail detail:list){
3. insert(detail);
4. }
优化后：
1. // 批量⼊库,mybatis demo实现
2. <insert id="insertBatch" parameterType="java.util.List">
3. insert into trans_detail( id,amount,payer,payee) values
4. <foreach collection="list" item="item" index="index" separator=",">(
5. #{item.id}, #{item.amount},
6. #{item.payer},#{item.payee}
7. )
8. </foreach>
9. </insert>
解析
批量插⼊性能更好，更加省时间，为什么呢？
1. 打个⽐喻：假如你需要搬⼀万块砖到楼顶，你有⼀个电梯，电梯⼀次可以放适量的砖（最多放500）,
2. 你可以选择⼀次运送⼀块砖，也可以⼀次运送500，你觉得哪种⽅式更⽅便，时间消耗更少?
2.耗时操作考虑异步处理
耗时操作，考虑⽤异步处理，这样可以降低接⼝耗时。本次转账接⼝优化，匹配联⾏号的操作耗时有点长，所以优化过程把它移到异步处理啦，如下：
优化前：
优化后
匹配联⾏号的操作异步处理
性能对⽐：
假设⼀个联⾏号匹配6ms
同步异步500条3000ms~1000条6000ms~
同步异步
解析：
因为联⾏号匹配⽐较耗时，放在异步处理的话，同步联机返回可以省掉这部分时间，⼤⼤提升接⼝性能，并且不会影响到转账主流程功能。
除了这个例⼦，平时我们类似功能，如⽤户注册成功后，短信邮件通知，也是可以异步处理的，这个优化建议⾹饽饽的~
所以，太耗时的操作，在不影响主流程功能的情况下，可以考虑开⼦线程异步处理的啦。
3.恰当使⽤缓存
在适当的业务场景，恰当地使⽤缓存，是可以⼤⼤提⾼接⼝性能的。这⾥的缓存包括：Redis，JVM本sql优化的几种方式
地缓存，memcached，或者Map 等。
这次转账接⼝，使⽤到缓存啦，举个简单例⼦吧~
优化前
以下是输⼊⽤户账号，匹配联⾏号的流程图
恰当使⽤缓存，代替查询DB表，流程图如下：
解析：
把热点数据放到缓存，不⽤每次查询都去DB拉取，节省了这部分查SQL的耗时，美滋滋呀~
当然，不是什么数据都适合放到缓存的哦，访问⽐较频繁的热点数据才考虑缓存起来呢~
4. 优化程序逻辑、代码
优化程序逻辑、程序代码，是可以节省耗时的。
我这⾥就本次的转账接⼝优化，举个例⼦吧~
优化前：
优化前，联⾏号查询了两次（检验参数⼀次，插⼊DB前查询⼀次），如下伪代码：
1. punlic void process(Req req){
2. //检验参数，包括联⾏号（前端传来的payeeBankNo可以为空，但是如果后端没匹配到，会抛异常）
3. checkTransParams(Req req);
4. //Save DB
5. saveTransDetail(req);
6. }
7. void checkTransParams（Req req）{
8. //check Amount,and so on.
9. amount)；
10. //check payeebankNo

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。