说实话，上周那个数据迁移的需求差点让我崩溃。要把老系统里那十万条用户数据一股脑全导进新库，本来以为是个小case，结果第一版代码跑起来进度条走得比我蜗牛还慢——整整5分钟！kan着日志里那一行行慢吞吞的输出，我就在想，这dou2024年了难道我们的数据库还在用算盘算数吗？

领导路过工位，瞥了一眼屏幕，眉头皱得Neng夹死苍蝇：“这么点数据要跑半天？Neng不Neng快点？”

那一刻，我深知必须得动真格的了。经过一下午的折腾，从SQL语句拼接到JDBC参数调优，再到多线程并发，硬是把时间压缩到了3秒。这中间的坑和经验，我觉得有必要好好复盘一下毕竟谁也不想半夜被运维 第一阶段：告别“愚蠢”的循环，拥抱拼接SQL

咱们先来kankanZui原始的写法。坦白讲，这种代码我见过太多次了甚至有些几年经验的“老鸟”为了省事也这么写。

// 方式1：循环单条插入
for  {
    userMapper.insert;
}

这有什么问题？问题大了去了！你想想，10万条数据，意味着你的应用要和数据库进行10万次网络握手，数据库要解析10万次SQL语句，还要开启和提交10万次事务。假设每次交互耗时3毫秒，光网络往返和解析就要300秒，也就是5分钟。这还是在数据库没压力的情况下要是稍微有点并发，这时间还得翻倍。

于是我想到了MyBatis的``标签，把一大堆数据拼成一条巨无霸SQL。

    INSERT INTO user  VALUES
    
    

代码逻辑上也Zuo个分批处理，别一次性把10万条dou塞进去，那样SQL字符串长得吓人。

int batchSize = 1000;
for ; i += batchSize) {
    int end = Math.min);
    List batch = userList.subList;
    userMapper.batchInsert;
}

这一招下去，效果立竿见影，时间直接从5分钟降到了30秒。提升了10倍，感觉是不是Yi经Ke以了？

别高兴太早。这里有个巨大的隐患：`max_allowed_packet`。这是MySQL的一个配置参数，限制了单个SQL包的Zui大长度。Ru果你一次拼个几千条数据进去，SQL长度一旦超过这个限制，直接报错。而且，这种超长的SQL，数据库解析起来也费劲，内存占用高得吓人。

第二阶段：开启JDBC的“外挂”，真正的批处理

30秒虽然比5分钟强多了但面对十万级数据，还是显得不够kan。这时候，就得祭出JDBC驱动层面的黑科技了。

hen多人不知道，MySQL的JDBC驱动里藏着一个参数：rewriteBatchedStatements。这个参数默认是false的，一旦你把它设为true，奇迹就会发生。

修改你的数据库连接URL，加上这行关键配置：

jdbc:mysql://localhost:3306/test?rewriteBatchedStatements=true

光改URL还不够，MyBatis的执行器模式也得换。默认的`SIMPLE`模式是一条条发的，我们需要切换到`BATCH`模式。这时候，别再用那个``拼接大SQL了回归到单条插入的写法，但是用批处理模式去执行。

@Autowired
private SqlSessionFactory sqlSessionFactory;
public void batchInsertWithExecutor {
    // 开启BATCH模式，第二个参数false表示不自动提交
    try ) {
        UserMapper mapper = sqlSession.getMapper;
        int batchSize = 1000;
        for ; i++) {
            mapper.insert);
            // 每满1000条，手动刷新一次防止内存溢出
            if  % batchSize == 0) {
                sqlSession.flushStatements;
                sqlSession.clearCache;
            }
        }
        // 刷新剩余的
        sqlSession.flushStatements;
        sqlSession.commit;
    }
}

这背后的原理其实挺有意思。在`ExecutorType.BATCH`模式下MyBatis会先把SQL语句缓存起来而不是立马发给数据库。配合`rewriteBatchedStatements=true`，MySQL驱动会在底层偷偷把这些`INSERT`语句重写成`INSERT INTO table VALUES , , `的形式。

这相当于我们既享受了代码层面循环插入的简单，又拿到了拼接SQL的高性Neng。而且，驱动帮我们控制了包的大小，不会触发`max_allowed_packet`限制。

这一套组合拳打下来耗时直接从30秒降到了8秒。这速度，Yi经Neng应付大部分场景了。

第三阶段：多线程并发，榨干CPU性Neng

但是咱们Zuo技术的，不就是要追求极致吗？8秒虽然快，但kan着日志里那单线程的跑法，我就觉得亏——现在的服务器动不动就是8核16核，你只用一个线程干活，剩下的7个dou在那儿摸鱼，这Neng忍？

既然单线程Neng跑8秒，那Ru果开4个线程并发跑，理论上是不是Neng到2秒？

说干就干。我们把这10万条数据切分成几份，扔进线程池里并行处理。不过这里有个坑，得注意一下：数据库连接池的大小限制了你的并发上限。别线程开了一堆，结果dou在等数据库连接，那就适得其反了。

public void parallelBatchInsert {
    // 线程数别瞎开，得根据数据库连接池来定，比如8个
    int threadCount = 8; 
    int batchSize = userList.size / threadCount;
    ExecutorService executor = Executors.newFixedThreadPool;
    List futures = new ArrayList<>;
    for  {
        int start = i * batchSize;
        int end =  ? userList.size :  * batchSize;
        List subList = userList.subList;
        futures.add -> {
            // 每个线程跑一个批处理任务
            batchInsertWithExecutor;
        }));
    }
    // 等待所有任务dou干完
    for  {
        try {
            future.get;
        } catch  {
            throw new RuntimeException;
        }
    }
    executor.shutdown;
}

这一步加上去，效果简直炸裂。从8秒直接干到了3秒！kan着那瞬间完成的数据导入，心里那叫一个舒坦。

终极方案：整合与细节

为了方便以后直接复用，我把这些逻辑封装成了一个Service。这里用到了`CountDownLatch`来确保所有线程dou跑完了再结束方法，比`future.get`稍微优雅那么一点点。

@Service
public class BatchInsertService {
    @Autowired
    private SqlSessionFactory sqlSessionFactory;
    /**
     * 高性Neng批量插入
     * 10万条数据实测约3秒
     */
    public void highPerformanceBatchInsert {
        if ) {
            return;
        }
        // 线程数控制，别超过CPU核心数太多
        int threadCount = Math.min.availableProcessors);
        int batchSize =  Math.ceil userList.size / threadCount);
        ExecutorService executor = Executors.newFixedThreadPool;
        CountDownLatch latch = new CountDownLatch;
        for  {
            int start = i * batchSize;
            int end = Math.min * batchSize, userList.size);
            if ) {
                latch.countDown;
                continue;
            }
            // 注意这里要new一个新的ArrayList，防止并发修改问题
            List subList = new ArrayList<>);
            executor.submit -> {
                try {
                    doBatchInsert;
                } finally {
                    latch.countDown;
                }
            });
        }
        try {
            latch.await;
        } catch  {
            Thread.currentThread.interrupt;
        }
        executor.shutdown;
    }
    private void doBatchInsert {
        try ) {
            UserMapper mapper = sqlSession.getMapper;
            for ; i++) {
                mapper.insert);
                // 每隔1000条刷新一次平衡内存与速度
                if  % 1000 == 0) {
                    sqlSession.flushStatements;
                    sqlSession.clearCache;
                }
            }
            sqlSession.flushStatements;
            sqlSession.commit;
        }
    }
}

还有几个不得不提的“坑”

虽然速度上去了但实际生产环境用的时候，还有几个细节得盯紧了不然出了问题排查起来Neng让你头秃。

1. 内存溢出风险

我刚才的例子是假设10万条数据Neng一次性加载到内存。但Ru果是千万级数据，你直接`List all = selectAll`，服务器的内存条估计要冒烟。这时候得用流式查询，或者分页读取。比如每次从老库查1万条，插完再查下一批，别贪多。

int pageSize = 10000;
int total = countTotal;
for  {
    List page = selectByPage;
    highPerformanceBatchInsert;
}

2. 自增主键的获取

Ru果你用了`useGeneratedKeys="true"`想要回填主键ID，那得小心了。开启`rewriteBatchedStatements=true`时老版本的MySQL驱动在返回自增ID时会出问题，可Neng会乱套或者报错。解决办法hen简单：把MySQL驱动升级到8.0以上的版本。

    ...

3. 事务管理

多线程环境下事务管理变得hen复杂。上面的代码里每个线程dou有自己的SqlSession和事务。Ru果中间某个线程挂了怎么回滚？这得kan你的业务需求。Ru果是全量覆盖，那失败重跑就行；Ru果是必须保证原子性，可Neng就得考虑分布式事务或者放弃多线程，退而求然后用单线程批处理。毕竟鱼和熊掌不可兼得嘛。

一下

回顾一下这场从5分钟到3秒的“极速之旅”，核心其实就三板斧：

优化阶段	关键动作	耗时变化
初始状态	for循环单条插入	5分钟
第一步	foreach拼接SQL + 分批提交	30秒
第二步	rewriteBatchedStatements + ExecutorType.BATCH	8秒
第三步	多线程并行处理	3秒

其实优化的本质无非就是：减少网络交互次数降低数据库解析开销充分利用计算资源。只要抓住了这三点，不管你是用MyBatis还是JPA，思路dou是通用的。

当然实际项目中别为了快而快，还得考虑代码的可维护性、出错率以及服务器的承受Neng力。不过当老板下次再问你“Neng不Neng再快点”的时候，你至少Neng掏出这几招镇场子了。

Ru果你在批量操作中还遇到过什么奇葩的坑，或者有geng骚的优化技巧，欢迎在评论区留言，咱们一起交流一下毕竟独乐乐不如众乐乐嘛！

---