你好，我是yes。
最近在压测一批接口，发现接口处理速度慢的有点超出预期，感觉很奇怪，前面定位发现是数据库批量保留这块很慢。
这个我的项目用的是 mybatis-plus，批量保留间接用的是 mybatis-plus 提供的 saveBatch。
我点进去看了下源码，感觉有点不太对劲：
我持续追踪了下，从这个代码来看，的确是 for 循环一条一条执行了 sqlSession.insert，上面的 consumer 执行的就是下面的 sqlSession.insert:
而后累计肯定数量后，一批 flush。
从这点来看，这个 saveBach 的性能必定比间接一条一条 insert 快。
我间接进行一个粗略的试验，简略创立了一张表来比照一波！
粗略的试验
1000条数据，一条一条插入
@Testvoid 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(); }}复制代码
能够看到，执行一批 1000 条数的批量保留，消耗的工夫是 121011 毫秒。
1000条数据用 mybatis-plus 自带的 saveBatch 插入
@Testvoid 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(); }}复制代码
消耗的工夫是 59927 毫秒，比一条一条插入快了一倍，从这点来看，效率还是能够的。
而后常见的还有一种利用拼接 sql 形式来实现批量插入，咱们也来比照试试看性能如何。
1000条数据用手动拼接 sql 形式插入
搞个手动拼接：
来跑跑下性能如何：
@Testvoid 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(); }}复制代码
耗时只有 2275 毫秒，性能比 mybatis-plus 自带的 saveBatch 好了 26 倍！
这时，我又忽然回想起以前间接用 JDBC 批量保留的接口，那都到这份上了，顺带也跑跑看！
1000条数据用 JDBC executeBatch 插入
@Testvoid 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(); }}复制代码
耗时是 55663 毫秒，所以 JDBC executeBatch 的性能跟 mybatis-plus 的 saveBatch 一样（底层一样）。
综上所述，拼接 sql 的形式实现批量保留效率最佳。
然而我又不太甘心，总感觉应该有什么别的法子，而后我就持续跟着 mybatis-plus 的源码 debug 了一下，跟到了 mysql 的驱动，忽然发现有个 if 外面的条件有点显眼：
就是这个叫 rewriteBatchedStatements 的玩意，从名字来看是要重写批操作的 Statement，后面batchHasPlainStatements 曾经是 false，取反必定是 true，所以只有这参数是 true 就会进行一波操作。
我看了下默认是 false。
同时我也上网查了下 rewriteBatchedStatements 参数，好家伙，如同有用！
我间接将 jdbcurl 加上了这个参数：
而后持续跑了下 mybatis-plus 自带的 saveBatch，果然性能大大提高，跟拼接 SQL 差不多！
顺带我也跑了下 JDBC 的 executeBatch ，果然也进步了。
而后我持续 debug ，来探探 rewriteBatchedStatements 到底是怎么 rewrite 的！
如果这个参数是 true，则会执行上面的办法且间接返回：
看下 executeBatchedInserts 到底干了什么：
看到下面我圈进去的代码没，如同曾经有点感觉了，持续往下 debug。
果然！ sql 语句被 rewrite了：
对插入而言，所谓的 rewrite 其实就是将一批插入拼接成 insert into xxx values (a),(b),(c)...这样一条语句的模式而后执行，这样一来跟拼接 sql 的成果是一样的。
那为什么默认不给这个参数设置为 true 呢？
我简略问了下 ChatGPT：
如果批量语句中的某些语句失败，则默认重写会导致所有语句都失败。
批量语句的某些语句参数不一样，则默认重写会使得查问缓存未命中。