@[toc]
上周松哥转载了一个数据批量插入的文章，里边和大家聊了一下数据批量插入的问题，批量插入到底怎么做才快。

有个小伙伴看了文章后提出了不同的意见：

松哥认真和 BUG 同学聊了下，基本上明确了这个小伙伴的意思，于是我本人也写了个测试案例，重新整理了明天这篇文章，心愿和小伙伴们一起探讨这个问题，也欢送小伙伴们提出更好的计划。

1. 思路剖析

批量插入这个问题，咱们用 JDBC 操作，其实就是两种思路吧：

  1. 用一个 for 循环，把数据一条一条的插入（这种须要开启批处理）。
  2. 生成一条插入 sql，相似这种 insert into user(username,address) values('aa','bb'),('cc','dd')...。

到底哪种快呢？

咱们从两方面来思考这个问题：

  1. 插入 SQL 自身执行的效率。
  2. 网络 I/O。

先说第一种计划，就是用 for 循环循环插入：

  • 这种计划的劣势在于，JDBC 中的 PreparedStatement 有预编译性能，预编译之后会缓存起来，前面的 SQL 执行会比拟快并且 JDBC 能够开启批处理，这个批处理执行十分给力。
  • 劣势在于，很多时候咱们的 SQL 服务器和应用服务器可能并不是同一台，所以必须要思考网络 IO，如果网络 IO 比拟费时间的话，那么可能会拖慢 SQL 执行的速度。

再来说第二种计划，就是生成一条 SQL 插入：

  • 这种计划的劣势在于只有一次网络 IO，即便分片解决也只是数次网络 IO，所以这种计划不会在网络 IO 上破费太多工夫。
  • 当然这种计划有好几个劣势，一是 SQL 太长了，甚至可能须要分片后批量解决；二是无奈充分发挥 PreparedStatement 预编译的劣势，SQL 要从新解析且无奈复用；三是最终生成的 SQL 太长了，数据库管理器解析这么长的 SQL 也须要工夫。

所以咱们最终要思考的就是咱们在网络 IO 上破费的工夫，是否超过了 SQL 插入的工夫？这是咱们要思考的外围问题。

2. 数据测试

接下来咱们来做一个简略的测试，批量插入 5 万条数据看下。

首先筹备一个简略的测试表：

CREATE TABLE `user` (  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,  `username` varchar(255) DEFAULT NULL,  `address` varchar(255) DEFAULT NULL,  `password` varchar(255) DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

接下来创立一个 Spring Boot 工程，引入 MyBatis 依赖和 MySQL 驱动，而后 application.properties 中配置一下数据库连贯信息：

spring.datasource.username=rootspring.datasource.password=123spring.datasource.url=jdbc:mysql:///batch_insert?serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true

大家须要留神，这个数据库连贯 URL 地址中多了一个参数 rewriteBatchedStatements，这是外围。

MySQL JDBC 驱动在默认状况下会忽视 executeBatch() 语句，把咱们冀望批量执行的一组 sql 语句拆散，一条一条地发给 MySQL 数据库，批量插入实际上是单条插入，间接造成较低的性能。将 rewriteBatchedStatements 参数置为 true, 数据库驱动才会帮咱们批量执行 SQL。

OK，这样筹备工作就做好了。

2.1 计划一测试

首先咱们来看计划一的测试，即一条一条的插入（实际上是批处理）。

首先创立相应的 mapper，如下：

@Mapperpublic interface UserMapper {    Integer addUserOneByOne(User user);}

对应的 XML 文件如下：

<insert id="addUserOneByOne">    insert into user (username,address,password) values (#{username},#{address},#{password})</insert>

service 如下：

@Servicepublic class UserService extends ServiceImpl<UserMapper, User> implements IUserService {    private static final Logger logger = LoggerFactory.getLogger(UserService.class);    @Autowired    UserMapper userMapper;    @Autowired    SqlSessionFactory sqlSessionFactory;    @Transactional(rollbackFor = Exception.class)    public void addUserOneByOne(List<User> users) {        SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH);        UserMapper um = session.getMapper(UserMapper.class);        long startTime = System.currentTimeMillis();        for (User user : users) {            um.addUserOneByOne(user);        }        session.commit();        long endTime = System.currentTimeMillis();        logger.info("一条条插入 SQL 消耗工夫 {}", (endTime - startTime));    }}

这里我要说一下：

尽管是一条一条的插入，然而咱们要开启批处理模式（BATCH），这样前前后后就只用这一个 SqlSession，如果不采纳批处理模式，反反复复的获取 Connection 以及开释 Connection 会消耗大量工夫，效率奇低，这种效率奇低的形式松哥就不给大家测试了。

接下来写一个简略的测试接口看下：

@RestControllerpublic class HelloController {    private static final Logger logger = getLogger(HelloController.class);    @Autowired    UserService userService;    /**     * 一条一条插入     */    @GetMapping("/user2")    public void user2() {        List<User> users = new ArrayList<>();        for (int i = 0; i < 50000; i++) {            User u = new User();            u.setAddress("广州：" + i);            u.setUsername("张三：" + i);            u.setPassword("123：" + i);            users.add(u);        }        userService.addUserOneByOne(users);    }}

写个简略的单元测试：

/** *  * 单元测试加事务的目标是为了插入之后主动回滚，防止影响下一次测试后果 * 一条一条插入 */@Test@Transactionalvoid addUserOneByOne() {    List<User> users = new ArrayList<>();    for (int i = 0; i < 50000; i++) {        User u = new User();        u.setAddress("广州：" + i);        u.setUsername("张三：" + i);        u.setPassword("123：" + i);        users.add(u);    }    userService.addUserOneByOne(users);}

能够看到，耗时 901 毫秒，5w 条数据插入不到 1 秒。

2.2 计划二测试

计划二是生成一条 SQL 而后插入。

mapper 如下：

@Mapperpublic interface UserMapper {    void addByOneSQL(@Param("users") List<User> users);}

对应的 SQL 如下：

<insert id="addByOneSQL">    insert into user (username,address,password) values    <foreach collection="users" item="user" separator=",">        (#{user.username},#{user.address},#{user.password})    </foreach></insert>

service 如下：

@Servicepublic class UserService extends ServiceImpl<UserMapper, User> implements IUserService {    private static final Logger logger = LoggerFactory.getLogger(UserService.class);    @Autowired    UserMapper userMapper;    @Autowired    SqlSessionFactory sqlSessionFactory;    @Transactional(rollbackFor = Exception.class)    public void addByOneSQL(List<User> users) {        long startTime = System.currentTimeMillis();        userMapper.addByOneSQL(users);        long endTime = System.currentTimeMillis();        logger.info("合并成一条 SQL 插入消耗工夫 {}", (endTime - startTime));    }}

而后在单元测试中调一下这个办法：

/** * 合并成一条 SQL 插入 */@Test@Transactionalvoid addByOneSQL() {    List<User> users = new ArrayList<>();    for (int i = 0; i < 50000; i++) {        User u = new User();        u.setAddress("广州：" + i);        u.setUsername("张三：" + i);        u.setPassword("123：" + i);        users.add(u);    }    userService.addByOneSQL(users);}

能够看到插入 5 万条数据耗时 1805 毫秒。

能够看到，生成一条 SQL 的执行效率还是要差一点。

另外还须要留神，第二种计划还有一个问题，就是当数据量大的时候，生成的 SQL 将特地的长，MySQL 可能一次性解决不了这么大的 SQL，这个时候就须要批改 MySQL 的配置或者看待插入的数据进行分片解决了，这些操作又会导致插入工夫更长。

2.3 比照剖析

很显著，计划一更具劣势。当批量插入十万、二十万数据的时候，计划一的劣势会更加显著（计划二则须要批改 MySQL 配置或者看待插入数据进行分片）。

3. MP 怎么做的？

小伙伴们晓得，其实 MyBatis Plus 里边也有一个批量插入的办法 saveBatch，咱们来看看它的实现源码：

@Transactional(rollbackFor = Exception.class)@Overridepublic boolean saveBatch(Collection<T> entityList, int batchSize) {    String sqlStatement = getSqlStatement(SqlMethod.INSERT_ONE);    return executeBatch(entityList, batchSize, (sqlSession, entity) -> sqlSession.insert(sqlStatement, entity));}

能够看到，这里拿到的 sqlStatement 就是一个 INSERT_ONE，即一条一条插入。

再来看 executeBatch 办法，如下：

public static <E> boolean executeBatch(Class<?> entityClass, Log log, Collection<E> list, int batchSize, BiConsumer<SqlSession, E> consumer) {    Assert.isFalse(batchSize < 1, "batchSize must not be less than one");    return !CollectionUtils.isEmpty(list) && executeBatch(entityClass, log, sqlSession -> {        int size = list.size();        int i = 1;        for (E element : list) {            consumer.accept(sqlSession, element);            if ((i % batchSize == 0) || i == size) {                sqlSession.flushStatements();            }            i++;        }    });}

这里留神 return 中的第三个参数，是一个 lambda 表达式，这也是 MP 中批量插入的外围逻辑，能够看到，MP 先对数据进行分片（默认分片大小是 1000），分片实现之后，也是一条一条的插入。持续查看 executeBatch 办法，就会发现这里的 sqlSession 其实也是一个批处理的 sqlSession，并非一般的 sqlSession。

综上，MP 中的批量插入计划跟咱们 2.1 大节的批量插入思路其实是一样的。

4. 小结

好啦，通过下面的剖析，当初小伙伴们晓得了批量插入该怎么做了吧？

松哥提供了一个测试案例，公众号后盾回复批量插入测试获取案例地址，案例中有三个单元测试办法，间接运行，就能够看到批量插入的工夫差别（数据库脚本在 resources 目录下）。

感兴趣的小伙伴无妨试试~

最初再次感激 BUG 童鞋提出的意见~