从120s到3s！MyBatis批量插入数据优化分享，那叫一个优雅！

小咪咪 2024-03-22 11:47 49阅读 0赞

### 概述 ###

最近在压测一批接口，发现接口处理速度慢的有点超出预期，感觉很奇怪，后面定位发现是数据库批量保存这块很慢。

这个项目用的是 `mybatis-plus`，批量保存直接用的是 `mybatis-plus` 提供的 saveBatch。

我点进去看了下源码，感觉有点不太对劲：

![972afbe5a2c81f78744a01aa9e9ea899.png][]

我继续追踪了下，从这个代码来看，确实是 for 循环一条一条执行了 `sqlSession.insert`，下面的 consumer 执行的就是上面的 `sqlSession.insert`:

![22538f1a849c0072e62a89aa6305efba.png][]

然后累计一定数量后，一批 flush。

从这点来看，这个 saveBach 的性能肯定比直接一条一条 insert 快。

我直接进行一个粗略的实验，简单创建了一张表来对比一波！

### 粗略的实验 ###

> 1000条数据，一条一条插入

@Test
    void MybatisPlusSaveOne() {
        SqlSession sqlSession = sqlSessionFactory.openSession();
        try {
            StopWatch stopWatch = new StopWatch();
            stopWatch.start("mybatis plus save one");
            for (int i = 0; i < 1000; i++) {
                OpenTest openTest = new OpenTest();
                openTest.setA("a" + i);
                openTest.setB("b" + i);
                openTest.setC("c" + i);
                openTest.setD("d" + i);
                openTest.setE("e" + i);
                openTest.setF("f" + i);
                openTest.setG("g" + i);
                openTest.setH("h" + i);
                openTest.setI("i" + i);
                openTest.setJ("j" + i);
                openTest.setK("k" + i);
                //一条一条插入
                openTestService.save(openTest);
            }
            sqlSession.commit();
            stopWatch.stop();
            log.info("mybatis plus save one：" + stopWatch.getTotalTimeMillis());
        } finally {
            sqlSession.close();
        }
    }

![544f9fabc58ddc1d80756b74a4ce71d3.png][]

可以看到，执行一批 1000 条数的批量保存，耗费的时间是 121011 毫秒。

> 1000条数据用 mybatis-plus 自带的 saveBatch 插入

@Test
    void MybatisPlusSaveBatch() {
        SqlSession sqlSession = sqlSessionFactory.openSession();
        try {
            List<OpenTest> openTestList = new ArrayList<>();
            for (int i = 0; i < 1000; i++) {
                OpenTest openTest = new OpenTest();
                openTest.setA("a" + i);
                openTest.setB("b" + i);
                openTest.setC("c" + i);
                openTest.setD("d" + i);
                openTest.setE("e" + i);
                openTest.setF("f" + i);
                openTest.setG("g" + i);
                openTest.setH("h" + i);
                openTest.setI("i" + i);
                openTest.setJ("j" + i);
                openTest.setK("k" + i);
                openTestList.add(openTest);
            }
            StopWatch stopWatch = new StopWatch();
            stopWatch.start("mybatis plus save batch");
            //批量插入
            openTestService.saveBatch(openTestList);
            sqlSession.commit();
            stopWatch.stop();
            log.info("mybatis plus save batch：" + stopWatch.getTotalTimeMillis());
        } finally {
            sqlSession.close();
        }
    }

![520faa54c21869b41c7e6a6be002673e.png][]

耗费的时间是 59927 毫秒，比一条一条插入快了一倍，从这点来看，效率还是可以的。

然后常见的还有一种利用拼接 sql 方式来实现批量插入，我们也来对比试试看性能如何。

> 1000条数据用手动拼接 sql 方式插入

搞个手动拼接：

![b28deba744b1b32c0ef8e65ed7cf7be8.png][]

来跑跑下性能如何：

@Test
    void MapperSaveBatch() {
        SqlSession sqlSession = sqlSessionFactory.openSession();
        try {
            List<OpenTest> openTestList = new ArrayList<>();
            for (int i = 0; i < 1000; i++) {
                OpenTest openTest = new OpenTest();
                openTest.setA("a" + i);
                openTest.setB("b" + i);
                openTest.setC("c" + i);
                openTest.setD("d" + i);
                openTest.setE("e" + i);
                openTest.setF("f" + i);
                openTest.setG("g" + i);
                openTest.setH("h" + i);
                openTest.setI("i" + i);
                openTest.setJ("j" + i);
                openTest.setK("k" + i);
                openTestList.add(openTest);
            }
            StopWatch stopWatch = new StopWatch();
            stopWatch.start("mapper save batch");
            //手动拼接批量插入
            openTestMapper.saveBatch(openTestList);
            sqlSession.commit();
            stopWatch.stop();
            log.info("mapper save batch：" + stopWatch.getTotalTimeMillis());
        } finally {
            sqlSession.close();
        }
    }

![7c2dc81ae9c6641c4cb43fba394b55a2.png][]

耗时只有 2275 毫秒，性能比 mybatis-plus 自带的 saveBatch 好了 26 倍！

这时，我又突然回想起以前直接用 JDBC 批量保存的接口，那都到这份上了，顺带也跑跑看！

> 1000条数据用 JDBC executeBatch 插入

@Test
    void JDBCSaveBatch() throws SQLException {
        SqlSession sqlSession = sqlSessionFactory.openSession();
        Connection connection = sqlSession.getConnection();
        connection.setAutoCommit(false);
    
        String sql = "insert into open_test(a,b,c,d,e,f,g,h,i,j,k) values(?,?,?,?,?,?,?,?,?,?,?)";
        PreparedStatement statement = connection.prepareStatement(sql);
        try {
            for (int i = 0; i < 1000; i++) {
                statement.setString(1,"a" + i);
                statement.setString(2,"b" + i);
                statement.setString(3, "c" + i);
                statement.setString(4,"d" + i);
                statement.setString(5,"e" + i);
                statement.setString(6,"f" + i);
                statement.setString(7,"g" + i);
                statement.setString(8,"h" + i);
                statement.setString(9,"i" + i);
                statement.setString(10,"j" + i);
                statement.setString(11,"k" + i);
                statement.addBatch();
            }
            StopWatch stopWatch = new StopWatch();
            stopWatch.start("JDBC save batch");
            statement.executeBatch();
            connection.commit();
            stopWatch.stop();
            log.info("JDBC save batch：" + stopWatch.getTotalTimeMillis());
        } finally {
            statement.close();
            sqlSession.close();
        }
    }

![a73ad110888ed0d0f7ea083f83f15678.png][]

耗时是 55663 毫秒，所以 JDBC executeBatch 的性能跟 `mybatis-plus` 的 saveBatch 一样（底层一样）。

综上所述，拼接 sql 的方式实现批量保存效率最佳。

但是我又不太甘心，总感觉应该有什么别的法子，然后我就继续跟着 mybatis-plus 的源码 debug 了一下，跟到了 mysql 的驱动，突然发现有个 if 里面的条件有点显眼：

![17f6c6c8ca15c1d51e1d5886d8d74f78.png][]

就是这个叫 rewriteBatchedStatements 的玩意，从名字来看是要重写批操作的 Statement，前面batchHasPlainStatements 已经是 false，取反肯定是 true，所以只要这参数是 true 就会进行一波操作。

我看了下默认是 false。

![fee44c3d318fc0b8792da47edbe10e91.png][]

同时我也上网查了下 rewriteBatchedStatements 参数，好家伙，好像有用！我直接将 jdbcurl 加上了这个参数：

![9df0852f829c5a378acac9c21a63ffb0.png][]

然后继续跑了下 `mybatis-plus` 自带的 saveBatch，果然性能大大提高，跟拼接 SQL 差不多！

![13e5daa0d51118187478fa2912a20e20.png][]

顺带我也跑了下 JDBC 的 executeBatch ，果然也提高了。

![bbbe22ee208fb62541e7b35b02338493.png][]

然后我继续 debug ，来探探 rewriteBatchedStatements 究竟是怎么 rewrite 的！

如果这个参数是 true，则会执行下面的方法且直接返回：

![9035ca72dba6d4c075af22e0717ff361.png][]

看下 `executeBatchedInserts` 究竟干了什么：

![d78af1ebd5de8c4efe4407a206563df8.png][]

看到上面我圈出来的代码没，好像已经有点感觉了，继续往下 debug。

果然！sql 语句被 rewrite了：

![3ad3bf30a88a3a65873c971afa1a5bab.png][]

对插入而言，所谓的 rewrite 其实就是将一批插入拼接成 `insert into xxx values (a),(b),(c)...`这样一条语句的形式然后执行，这样一来跟拼接 sql 的效果是一样的。

那为什么默认不给这个参数设置为 true 呢？

原来是这样的：

1.  如果批量语句中的某些语句失败，则默认重写会导致所有语句都失败。
2.  批量语句的某些语句参数不一样，则默认重写会使得查询缓存未命中。

看起来影响不大，所以我给我的项目设置上了这个参数！

### 最后 ###

稍微总结下我粗略的对比（虽然粗略，但实验结果符合原理层面的理解），如果你想更准确地实验，可以使用JMH，并且测试更多组数（如 5000，10000等）的情况。

<table> 
 <thead> 
  <tr> 
   <th>批量保存方式</th> 
   <th>数据量（条）</th> 
   <th>耗时（ms）</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>单条循环插入</td> 
   <td>1000</td> 
   <td>121011</td> 
  </tr> 
  <tr> 
   <td>mybatis-plus saveBatch</td> 
   <td>1000</td> 
   <td>59927</td> 
  </tr> 
  <tr> 
   <td>mybatis-plus saveBatch(添加rewtire参数)</td> 
   <td>1000</td> 
   <td>2589</td> 
  </tr> 
  <tr> 
   <td>手动拼接sql</td> 
   <td>1000</td> 
   <td>2275</td> 
  </tr> 
  <tr> 
   <td>jdbc executeBatch</td> 
   <td>1000</td> 
   <td>55663</td> 
  </tr> 
  <tr> 
   <td>jdbc executeBatch(添加rewtire参数)</td> 
   <td>1000</td> 
   <td>324</td> 
  </tr> 
 </tbody> 
</table>

所以如果有使用 jdbc 的 Batch 性能方面的需求，要将 rewriteBatchedStatements 设置为 true，这样能提高很多性能。

然后如果喜欢手动拼接 sql 要注意一次拼接的数量，分批处理。

[972afbe5a2c81f78744a01aa9e9ea899.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/6f465270be1141baa1a3985fe65767c5.png
[22538f1a849c0072e62a89aa6305efba.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/27874c0770b742fdbe6fbcad22c77881.png
[544f9fabc58ddc1d80756b74a4ce71d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/704a8aa4d32c44e185de5ce07662ee7c.png
[520faa54c21869b41c7e6a6be002673e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a8acc5dca224433da9ba37b2ed75e6d2.png
[b28deba744b1b32c0ef8e65ed7cf7be8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0bcdade746de458cb211318357df5026.png
[7c2dc81ae9c6641c4cb43fba394b55a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/3d95107e01aa412a9b713253096fd89e.png
[a73ad110888ed0d0f7ea083f83f15678.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/bd54c068cdbe41cfafb2203f547766fe.png
[17f6c6c8ca15c1d51e1d5886d8d74f78.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0396e3026f164179826dfa04c39e9059.png
[fee44c3d318fc0b8792da47edbe10e91.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/5787b20cdd494ed79fd34b76794911b8.png
[9df0852f829c5a378acac9c21a63ffb0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/11ce6b36d793410294e0474978b6d2b4.png
[13e5daa0d51118187478fa2912a20e20.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/06b0aa60ca724cf7b09383a3c099c7f7.png
[bbbe22ee208fb62541e7b35b02338493.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f112b6d5a0194b24a2bfbeccdcd79930.png
[9035ca72dba6d4c075af22e0717ff361.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/cbf4ef561b7f4e559bc28d5c363182c2.png
[d78af1ebd5de8c4efe4407a206563df8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0d4913d4dac94c84a307abf8a662260d.png
[3ad3bf30a88a3a65873c971afa1a5bab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d27c82435a1f4fae812032b525d4b0d1.png