SaveOrUpdate批量性能低？原来是使用的姿势不对

SaveOrUpdate批量性能低？

​ Mybatis Plus提供了批量操作接口，SaveBtach、UpdateBatch、SaveOrUpdateBatch，极大地提高了我们的工作效率。不过，近期在对老项目优化的过程中，发现了一个性能问题。

​ 引子：公司需要给表格增加全选按钮，一键勾选所有需要操作的数据行。没加全选按钮之前，一个页面最多展示200条数据，用户最多选中200条来执行操作，执行操作响应略长一些，还可以接受。加全选按钮之后，用户可以一键勾选所有数据，数据量可就上万了。测试发现后台响应特别的慢。

根因：

​ 分析后台日志，一次操作流程中出现了大量相同结构的sql请求，区别只是id参数不同而已。走读代码，定位到使用了Mybatis Plus提供的SaveOrUpdateBatch方法。

解决方案：

​ 经过排查，是jdbc未开启rewriteBatchedStatement导致的。Mybatis的Batch Executor依赖于jdbc的sql重写功能，但重写功能默认是关闭的。最终，打开重写功能即可。

application-db.yml: 修改jdbc连接属性

url: jdbc:mysql://xxx:3306/xx?xxx&rewriteBatchedStatement=true

Tips:

• saveBatch、updateBatch: 可放心使用，不存在性能问题。

• saveOrUpdateBatch: 存在隐藏的性能问题，可使用场景：新增多（且新增数据的id为null），更新少。

​ saveOrUpdateBatch即保存或更新，这是两个不同的操作。一条数据是需要执行保存操作，还是更新操作，mp框架会进行推断。推断逻辑：(1) 如果该数据中id字段为null, 一定是新增 （2）如果该数据中id字段不为null, mp框架拿着id去数据库查一次，如果根据id没查到数据，则本次是需要插入；否则，本次是需要更新。

​ 这个推断过程就是一个隐患，假设现在有100条数据要操作，其中10条要做的是插入，90条是更新。那么，推断过程就会至少有90次sql请求。如果数据量更大，显然是不合理的。