Mybatis-plus批量插入性能测试
一、主要业务场：
前端发起1w+的业务数据，经过查各种表数据归类，最终得到一张表数据的List<Object>类型，然后需要对该List<Object>入库，数据库为mysql（其实oracle也一样）。由于该系列操作是同步的，从界面选择数据，选1w+数据量，点击保存，此时需要经过查数据，归类，汇总，入库这四个步骤，每一个步骤的耗时，都会影响界面的响应时间，响应越长，前端转圈时间越长，客户体验越不好。
为了提高响应时间，查数据，归类，汇总，入库，四个步骤，都必须讲究效率问题，优化每一个步骤，每一个细节。
第一步优化：涉及sql查询的，耗时超过2s的慢查询，改sql+添加索引方式，已经调试到了ms的范围。
第二和第三步优化：涉及归类，汇总，此时会有很多循环求和，循环赋值等等操作，使用分片+多线程方式，最终汇总到一个List<Object>，也优化到了5s内（1w+数据量循环效率比不上jdk的stream流，可以用arthas的trace分析）
第四步瓶颈：前两步已经把响应时间卡在了4-5s内能完成，但是入库操作非常耗时，1w+的数据量插入数据库，花了8-10s的时间，整个请求的响应全卡在了这一步。
然后找了Mybatis-plus官网，也逛了很多贴子，有说foreach性能高的，有说BATCH模式性能高的，什么都有，牛鬼蛇神等等。
基于每一种方法，均作了实验，得出一些心得，作此文记录下过程
二、性能测试：（用for单独一条条insert的方式，很low，谁都知道性能最低，不讨论）
1、第一种方法：foreach拼sql
模拟业务数据表，字段非常多，起码有30-40+以上，索引有3个以上，这种情况 2w 笔数据入库，List<Object>分片执行，1000条执行一次，如下图：
2、第二种方法，Mybatis-plus自带的saveBatch（就是Myabtis的BATCH处理模式）
同上，分片执行，好处在于不需要写xml，很清爽，很简洁，但是mysql需要配置一个jdbc参数：rewriteBatchedStatements=true，不然BATCH模式不生效，执行如下图：
总结下两者区别：
为什么有的帖子说foreach性能高？
原因很简单，那些帖子做测试的时候的表字段，5个不到，执行当然快，当你的表字段非常多的时候（不扯建表规范，字段过多的场景），foreach拼接的字段就会拉的长，执行的时间就会很长，当超过一定量的时候，会适得其反，效率下降
为什么有的帖子说BATCH模式性能好？
BATCH模式的性能也不好，看下saveBatch的源码就知道了
源码图：虽然叫批处理模式，实质上还是一条条的sql去执行，但是它做了预编译优化，只编译一次sql，但是还是一个for循环，一条执行一次，数据量多的时候，效率也不见得很好
结论：
1、BATCH模式其实是一个假的批处理模式，实质还是for循环一条条来执行，但是也会缓存一定量后一次性刷盘(比真正的for insert要好很多)，当字段比较少的时候，效率比不过foreach一次性执行效率高。
2、foreach用在字段比较少的表插入时候，性能确实比BATCH模式好，但字段多的时候，效率会下降严重，比不过BATCH模式，并且手动拼接sql，还容易出错，且繁琐耗时。
TIPS：
Mybatis-plus也提供了foreach一次性拼接sql的方式，且不用写任何的xml，只需增加一个sql注入器+接口+交给spring管理即可，跟foreach是一样执行方式，效率一样。
最终选择插入方式：
经过多轮测试，决定使用saveBatch的方式去实现业务，单线程插入1w+需要6-8s这样，多线程2s执行完，大大缩短了耗时，但是多线程得控制好事务一致性，出异常需要手动回滚数据，此时线程也不可开太多，控制内存的消耗，防止oom发生。
