MySQL批量插入性能优化：最佳批次大小与实战指南

做后端开发的兄弟应该都遇到过这个场景：往MySQL里导一批数据，比如一张表几十万条，如果一条一条INSERT进去，慢到怀疑人生；但如果你把SQL拼成一条大的批量INSERT，一次性塞进去一万条，可能又直接报错或者把数据库搞死。于是大家都在问：一次到底批量插入多少条数据性能最佳？

这个问题在面试里也经常出现，很多人的回答是“500条”“1000条”，但你要问他为什么，他就说不清了。这篇文章我就从底层原理、实测数据、工程实践三个角度把这个事儿掰开揉碎讲清楚，看完你不仅能回答面试官，还能在实际项目里把导入速度优化几个数量级。文章里提到的所有方案和参数，都是我这些年实打实调试过的，也踩过不少坑，希望能帮你少走弯路。

1. 为什么批量插入天生就比逐条插入快

1.1 一次网络往返 vs 一万次网络往返

先看最直观的差别：网络开销。

逐条插入时，客户端和MySQL之间要完成一万次SQL发送和结果返回。每次往返都有固定成本，内网环境大概0.1到1毫秒，跨机房可能到10毫秒以上。别小看这个数字，逐条插入一万条，光网络等待就要吃进去1到10秒，这还不算SQL解析和真实写入的时间。

批量插入的本质，就是把这个“网络往返次数”压缩。原本一万条SQL变成100条SQL，或者100条多VALUES语句，网络交互次数直接下降两个数量级。如果你用JDBC的rewriteBatchedStatements，驱动还会把一批预处理语句合并成一条真正的多VALUES语句，网络开销被压到最低。这个差异在短小SQL上尤其明显，因为短SQL本身执行很快，网络往返反而成了最大瓶颈。

1.2 SQL解析和权限检查的固定成本

MySQL处理一条INSERT，并不是直接写数据那么简单。它要先对SQL文本做词法分析、语法分析，然后查权限、生成执行计划，最后才走到存储引擎层。这些步骤每一步都有固定开销，而且和插入多少行关系不大。

你插入一万条单条SQL，就要重复一万次“解析+优化+执行计划生成”。但如果你把一万条合并成一条多VALUES语句，这些固定开销只付一次。也就是说，批量插入省掉的不仅仅是网络时间，还有MySQL服务端SQL层的大量重复劳动。这一点在行数少、单行数据短的情况下体现得最明显——固定成本占比高，批量化收益就大。

1.3 事务提交和日志刷盘的成本压缩

默认情况下，MySQL的autocommit是开启的，每条INSERT都会提交一个事务。事务提交要做什么？写undo log、写redo log、写binlog，并且根据刷盘参数决定是否调用fsync。如果innodb_flush_log_at_trx_commit=1且sync_binlog=1，每次提交都要等待磁盘物理落盘，这个代价非常昂贵。

这里有个容易被忽略的细节：一条多VALUES的INSERT，即使autocommit是开启的，MySQL也会把它当成一个隐式事务来处理，只提交一次。也就是说，一万行分成十批插入，事务提交次数只有十次；逐条插入的话，就是一万次事务提交。磁盘fsync的耗时通常以毫秒计，省下几千次fsync意味着什么，动手导过数据的人都懂。

1.4 索引页缓存和change buffer的辅助

InnoDB在写入时，数据页会缓存在buffer pool里。批量插入同一批数据时，主键连续的情况下，页面命中率很高，减少了磁盘读的等待。另外，表上的二级索引更新，如果索引页不在内存里，InnoDB会借助change buffer把二级索引的修改先缓存起来，后续再合并刷盘。逐条插入时这种合并机会少，批量插入时更容易触发。

所以批量插入的性能优势不是单一因素，而是“网络、SQL层、事务层、存储引擎层”四个层面的累积收益。理解了这些，你就知道为什么有些优化方案效果不明显——比如你只改了批量大小，但JDBC驱动没开rewriteBatchedStatements，事务固定成本根本没降下来，性能自然上不去。

2. 决定一次能插多少条的硬性限制

2.1 max_allowed_packet是最大的“包”

MySQL服务端和客户端都有一个max_allowed_packet参数，用来限制单次通信包的最大字节数。MySQL 8.0默认是64MB，但很多老版本默认只有4MB或者16MB。批量INSERT会被封装成一个网络包发给服务端，如果SQL文本总长度超过这个值，服务端直接断开连接或者报错。

最常见的报错是：Got a packet bigger than 'max_allowed_packet' bytes。很多人遇到这个错误，第一反应是去调大max_allowed_packet，但这是治标不治本。更合理的做法是控制每个批次的SQL大小，给max_allowed_packet留出足够余量。默认64MB的环境下，我建议单批SQL控制在10MB以内，这既能避开参数限制，也能避免大网络包在传输层出问题。

2.2 事务过大带来的undo和锁问题

每批插入其实就是一个事务。行数太多，事务的undo log会膨胀，回滚段压力大。如果中途某一行数据有问题导致整个事务回滚，大批次回滚的速度慢得惊人，而且回滚期间锁一直持有，会阻塞其他查询。

我实际遇到过一档子事：一批插入5万行，里面有一行出现了主键冲突，整个事务回滚，DBA差点打电话骂人。后来我们都按“单事务操作几千行”来约束业务代码，既保证性能，又把回滚影响控制在可接受范围。记住一个原则：批次大小 = 事务大小，大事务是数据库的隐形杀手。

2.3 行宽和索引数量决定了“条数”没有意义

“一次插多少条最佳”这个问法本身就有问题，因为不同行的宽度完全不同。一行十几个int字段，和一行十几个varchar(255)加两个TEXT字段，同样是一千行，SQL体积差出几十倍。索引数量更是关键，每多一个二级索引，插入成本就增加一份，五个索引的表和没有索引的表，插入速度能差出几倍。

所以更科学的衡量标准是“单批SQL的字节数”，而不是“条数”。单行100字节的表，插2000条也就200KB，非常安全；单行10KB的表，插200条就已经2MB了，再往大走就要小心。我习惯用“单行大小乘以批次条数”来估算单批SQL的体积，控制在1MB以内，然后根据实际测试微调。

2.4 驱动缓冲区和网络传输的影响

不只是MySQL服务端有限制，客户端也有。MySQL JDBC驱动内置的maxAllowedPacket参数，默认同样遵循服务端配置。如果你在JDBC URL里没显式配置，驱动可能默认最大16MB或64MB，超过这个值依然会报错。

网络传输层面，一条10MB的大SQL在TCP上会被分成很多个分段，一旦中间丢包，重传的代价比小包高得多。我在跨机房导入数据时就发现，批次特别大的时候，偶尔会出现超时或者连接被重置，后来把批次减小，这个问题就消失了。网络环境越差，越要控制单批SQL大小，别贪多。

3. 实测不同批量大小下的性能表现

3.1 一套可复现的测试环境和方案

为了方便说明，我整理了一次实际测试的数据。测试环境是MySQL 8.0.x，InnoDB引擎，innodb_flush_log_at_trx_commit=1，sync_binlog=1，也就是最“安全”但也最慢的配置。表结构是id bigint自增主键、a int、b varchar(64)、c datetime，没什么花哨的东西。

测试方式是使用JDBC，开启rewriteBatchedStatements=true，插入总量是100万行，分别按每批1条、100条、500条、1000条、2000条、5000条、10000条来跑。这个测试配置是很多生产环境的缩影，有参考价值，但具体数字在不同机器上会有差异，重点看变化趋势。

3.2 测试结果：从1到100是质变，从100到1000是量变

我直接说结果：

从1条到100条，性能提升了大概十倍，这是批量插入收益最大的区间。从100条到1000条，速度继续提升，但幅度明显放缓。到5000条以后，耗时基本不再下降，甚至有些环境因为SQL文本暴涨、解析耗时增加，反而出现轻微变慢。这就说明：批量插入的性能曲线是一条“先陡升、后放缓、最后趋平甚至回落”的曲线，不存在“越大越好”。

3.3 为什么超过一定规模后性能不再提升

原因不复杂。批量插入的收益来自摊薄固定开销，但这个固定开销在整体耗时中的占比是有限的。当批次已经足够大时，固定开销占比降得很低，继续增大批次只是在增加单次SQL的传输时间、解析时间和服务端的内存占用。

更麻烦的是大事务的副作用。一万行一个批次，undo log膨胀、锁持有时间长、失败回滚代价大。主从复制场景下，一条大SQL到了从库还是要整体执行，如果从库性能弱，很容易产生复制延迟。以前我遇到过一个主库插入很快、从库延迟几十秒的案例，后来发现就是把批次加得太大，从库一个事务执行太久，延迟自然就出来了。

3.4 所以“最佳批次”到底是多少

结合实测和自己的经验，我给出的参考答案是：常规业务环境，单批500到1000条，同时控制单批SQL大小在1MB以内。如果数据量特别大、表结构简单、你能接受失败重试的成本，可以尝试到2000到5000条，但不要超过max_allowed_packet的一半。这个区间兼顾了性能、稳定性和可维护性。

这条结论不是拍脑袋，而是基于上面四层固定开销原理和实测曲线得出的。你如果在面试里这么回答，再补充一点“要看行宽、索引数量、事务大小和驱动配置”，面试官基本就会觉得你是真做过优化的，而不是背了个数字。

4. 不同开发场景下的批量插入正确姿势

4.1 JDBC批量插入：不开rewriteBatchedStatements等于白干

JDBC的原生批量接口是PreparedStatement的addBatch和executeBatch，很多人写完之后发现性能提升并不明显，一度以为是MySQL不支持批量。其实不是MySQL不支持，而是JDBC驱动默认根本没把批量语句合并成一条多VALUES语句，它还在逐条发送。

要让JDBC驱动启用真正的批量优化，必须在连接URL上加参数：

java复制String url = "jdbc:mysql://localhost:3306/test"
    + "?rewriteBatchedStatements=true"
    + "&useServerPrepStmts=true";

加上rewriteBatchedStatements=true之后，驱动会把批次里的语句重写成INSERT INTO t VALUES (...), (...), ... 的形式，性能立刻上一个台阶。这个参数对PreparedStatement和普通Statement都有效，但有一个副作用要提一下：如果你在批量插入后通过getGeneratedKeys()获取自增主键，重写后的语句默认只能取到第一行的ID，需要在驱动参数里额外处理，否则会拿到错误的结果。

4.2 MyBatis Plus的saveBatch和自定义批量SQL

MyBatis Plus的ServiceImpl.saveBatch()默认批大小是1000条，内部通过ExecutorType.BATCH机制执行。但注意，你不一定自动享受到了rewriteBatchedStatements的优化，因为很多Spring Boot项目使用的是HikariCP连接池，如果你没在JDBC URL上配置rewriteBatchedStatements=true，saveBatch的批量效果也会打折扣。

如果你在XML里自己写批量INSERT，最常见的写法是foreach拼接：

xml复制<insert id="batchInsert">
    INSERT INTO t (a, b, c) VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.a}, #{item.b}, #{item.c})
    </foreach>
</insert>

这种写法很直观，但有一个隐患：如果list里面有五万条数据，生成的SQL文本会非常长，很可能直接触发max_allowed_packet。所以即使用了foreach，也必须在Java层分批，每批传1000条左右进去。我之前看到一个同事把一万条直接塞进foreach，跑完一批就报错，排了半天才发现是SQL体积超过了服务端限制。

4.3 文件导入场景：LOAD DATA INFILE才是终极大招

如果数据来源是文件，不要用INSERT拼SQL，直接上LOAD DATA INFILE。它绕过了SQL解析层，直接把数据文件按行导入到表里，速度比批量INSERT还快很多倍。MySQL 8.0里使用LOAD DATA LOCAL INFILE要确认local_infile参数已开启，而且要注意local表示文件在客户端上，普通INFILE表示文件在服务端上。

在DBeaver这类图形工具里，用“Import Data”功能导入CSV，本质也是走LOAD DATA或者分批INSERT，比直接在编辑器里执行一个几十MB的SQL脚本靠谱得多。热搜里有人说“DBeaver导入批量插入报错，单独执行正常”，十有八九就是SQL文件里某一条INSERT包含太多行了，拆小批次或者改用导入功能就行。

4.4 事务边界的控制：批大小和提交频率保持一致

手动写导入程序时，我见过很多新手把十万条数据放在一个事务里，最后提交。这样一旦出错，整个十万条全部回滚，数据库半死不活。我的做法是手动关掉自动提交，每处理一批就提交一次：

java复制conn.setAutoCommit(false);
for (int i = 0; i < rows.size(); i += batchSize) {
    List<Row> batch = rows.subList(i, Math.min(i + batchSize, rows.size()));
    for (Row row : batch) {
        ps.addBatch(row);
    }
    ps.executeBatch();
    conn.commit();
}
conn.setAutoCommit(true);

这样做的好处是：每一批的失败影响范围有限，重跑那一批就行，不需要整个任务重新执行。批大小和事务边界一致，也让日志排查变得容易——坏在哪个批次，日志里一看就知道。

5. 大规模数据导入的分批与事务策略

5.1 50万条数据的完整导入思路

假设你拿到一个CSV，里面有50万条数据要导入MySQL。不要想着一次INSERT搞定，也不要只靠“手动分批”敷衍了事，而是要有一整套流程：

先把原文件做一次清洗，去重、格式化日期、检查必填字段，避免放到数据库里再报错。然后关闭自动提交，每500到1000条一批，逐批executeBatch，每批commit。如果中途失败了，记录当前批次序号，修复数据后从这一批继续跑，不用从头再来。

同时评估表上的索引。如果表已经存在，导入期间可以把非必要的二级索引先drop掉，导完再建。这里要算一笔账：边插边维护索引，每一行都要写多个索引页，开销极大；导入完一次性建索引，虽然是全表扫描排序建树，但整体往往比边插边维护快很多。当然，如果数据量只有几百条，这个优化没必要做，收益不明显。

5.2 关闭外键检查的边界条件

SET FOREIGN_KEY_CHECKS=0是导入大批量数据时常用的“开关”。关闭外键检查后，MySQL不再校验子表外键引用，插入速度会提升一些。但要特别注意：这个参数只能跳过外键校验，不能跳过唯一键校验，也不能跳过主键冲突检查。更关键的是，如果你关闭了外键检查又导入了不一致的数据，后续打开外键检查时，历史数据的校验才会暴露问题。

所以我的建议是：新库或者临时表可以关，生产环境在导入前先确认数据完整性，导入过程中保持外键检查开启。别为了追求速度埋下数据质量的雷，导完之后被线上业务查出父子表对不上，那才叫真正的灾难。

5.3 动态调整批次大小：比固定值更实用

批次大小不是拍脑袋定完就不动了。我的习惯是写一个简单的测速逻辑，先跑100条、500条、1000条三组，统计每秒插入行数，选最快的那组作为基准。如果数据里有大文本字段，或者磁盘压力出现波动，再把批次减半。

代码里也可以做自适应：

java复制int batchSize = 1000;
long lastCost = Long.MAX_VALUE;
while (hasMoreData) {
    long start = System.currentTimeMillis();
    // 插入一批 batchSize 条
    long cost = System.currentTimeMillis() - start;
    if (lastCost != Long.MAX_VALUE && cost > lastCost * 1.5) {
        batchSize = batchSize * 2 / 3; // 变慢了，减小批次
    } else if (cost < lastCost / 2 && batchSize < 5000) {
        batchSize = batchSize * 3 / 2; // 明显变快，尝试增大
    }
    lastCost = cost;
}

这个策略不保证最优，但能帮你应对数据分布不均的情况。比如某些行包含很长的TEXT字段，固定批次可能导致SQL体积突然暴涨，动态调小批次就能避免这个问题。

5.4 并行导入的正确打开方式

单线程插入慢，很多人第一反应就是多线程并行。并行确实能提高吞吐量，但有几个坑必须提前知道。

InnoDB在并发写入时，会有锁竞争、redo log写入竞争和自增锁竞争。自增主键的表，高并发批量插入会造成auto-inc锁等待，反而拖慢整体速度。我的建议是：线程数控制在4到8个，再多收益不大；数据分片按主键区间或者hash取模切分，每个线程只导入自己那一片，互不干扰；每个线程独立事务，避免跨线程共享连接。

如果表上没有自增主键，而是一个业务唯一键，并行前先按这个键做分片，保证同一键值不会同时出现在多个线程里，否则可能出现重复插入或者死锁。并行是把双刃剑，用好了四倍速度，用不好数据库CPU打满、锁等待飙红。

6. 批量插入常见问题与排查实录

6.1 “Got a packet bigger than ‘max_allowed_packet’ bytes”

这个报错是批量插入的头号敌人，我几乎每年都会遇到几次。核心原因就是单条SQL文本长度超过了服务端的max_allowed_packet。常见场景是把一万行数据拼成一条INSERT，然后扔给DBeaver或者命令行执行，直接爆掉。

排查步骤很固定。先用SHOW VARIABLES LIKE 'max_allowed_packet';查看当前值，然后在代码里打印SQL字符串长度，对比两者。如果SQL长度确实超了，优先减小批次，把单批条数砍一半，而不是盲目调大参数。max_allowed_packet不是不能调，但调大后客户端和本地驱动参数都要同步改，而且它只是兜底，不是让批次无限膨胀的挡箭牌。

6.2 为什么批量插入后IO性能明显下降了

批量插入本身不会让IO变差，变差通常是两个原因：日志刷盘太频繁，或者数据文件碎片化严重。如果导入过程中开启了太多线程，每个线程都在提交事务，fsync次数成倍增加，磁盘io就顶不住了。

遇到IO性能明显下降，先看两个参数：innodb_flush_log_at_trx_commit和sync_binlog。如果都是1，每次事务提交都要求redo日志和binlog物理落盘，这是最安全但最慢的模式。如果业务能接受最多丢一秒数据，可以把innodb_flush_log_at_trx_commit调成2，sync_binlog调成0或1000，IO压力会小很多。生产环境要权衡数据安全性，这个调整需要DBA评估。

6.3 DBeaver导入批量插入报错但单独执行正常

这个现象几乎可以断定是SQL文件里某一条INSERT语句的规模超出了限制。单独执行一条INSERT当然没问题，但DBeaver执行整个脚本时，那一条包含五千行的INSERT就在一次通信里发给了MySQL，直接撞上max_allowed_packet。

在DBeaver里导入大数据集，有两个更靠谱的方案：一是用它的“Import Data”功能，按文件流方式逐行导入，不会生成超大SQL；二是先把数据拆成多个小SQL文件，每个文件里只放几百行一个批次，再逐个执行。别为了省事把一个几十MB的SQL文件直接拖进去执行，那是在赌数据库的承受能力。

6.4 批量插入慢到离谱，先查驱动再查表

如果你开了批量，代码看着也对，但速度就是提不上去，我建议按这个顺序排查。

先确认JDBC驱动真的启用了rewriteBatchedStatements，很多连接池配置不会自动带上这个参数。然后看表上有多少索引，二级索引太多的表，插入慢是必然。接着看是否有其他会话锁表，用SHOW ENGINE INNODB STATUS查看锁等待。最后看磁盘，iostat看一下util是否已经接近100%。这几个方向排完，基本能定位到问题所在。

有一个经验之谈：很多人觉得批量插入越慢越应该加大批次，这是个误区。有时候慢是因为单批事务太大、undo膨胀，减小批次反而更快。遇到性能异常，先做小批量测试对比，别急着往上加。

6.5 写一个SQL体积的快速估算表

为了让你在实际开发中快速判断批次大小是否合理，我按单行体积列了一个参考表。这个表是我根据常见表结构整理的经验值，直接用问题不大。

看到没，同样是“最佳批次”，在不同表结构下差异能达到几十倍。所以如果有人给你一个固定数字，比如“必须1000条”，你反而要慎重。真正的优化思路是理解背后那几条硬约束，然后根据实际情况调参。

回到开头那个问题：MySQL一次批量插入多少条数据性能最佳？

我的答案是：默认从500到1000条开始测，单批SQL控制在1MB以内；优先开启JDBC的rewriteBatchedStatements；每批一个事务，失败影响范围可控。数据量大的场景，结合索引调整、动态批次大小和适当并行，把这套组合拳打下来，导入性能通常能比逐条插入快几十倍。

最后再分享一个小技巧：别只在本地环境测试，生产环境的磁盘能力、内存大小、网络延迟都会影响最优批次。你可以在线上维护窗口期，拿少量数据先做三组不同批次的小实验，用数据说话，比任何经验值都靠谱。批量插入没有万能数字，但它背后的原理和排查方法，才是真正值钱的东西。