有一次面试，问懵了一个工作三年的开发

前段时间团队招人，我顺口问了一个自己都觉得很普通的问题：“MySQL一次批量插入多少条数据性能最佳？”

对面沉默了十几秒，然后说：“500条？网上都这么说。”

我再追了一句：“为什么是500条？500条和5000条差在哪？瓶颈在CPU还是磁盘？你要是换一个机器配置，这个数字还成立吗？”

他彻底卡住了。

这不是他的问题，是这个领域里几乎所有人都在“背答案”而不是“理解答案”。MySQL的批量插入性能问题，看起来是个数值问题，本质上是个系统问题——它牵扯到网络、日志、事务、内存、磁盘刷盘机制、主从复制架构，甚至Java驱动的底层实现。今天我把这个问题掰开揉碎了讲清楚，给你一套能自己推导结论的方法论，而不是一个死数字。

1. 问题背后的本质：批量插入慢，到底慢在哪

很多人一开始就搞错了方向，以为批量插入的性能问题单纯是“SQL语句怎么拼”的问题。实际上，当你从一次插入1条变成一次插入几百条、几千条时，性能变化来自多个层面的共同作用。

第一层，网络往返。 假设你用的是Java应用连接MySQL，每执行一条插入SQL，应用和数据库之间至少要经历一次“发送请求-等待执行-接收响应”的往返。一次往返耗时哪怕只有0.2毫秒，插入10万条数据就是2万秒，这还没算执行时间。批量插入最直接的红利就是砍掉了这部分开销——原来要往返1万次，现在只需要几百次。

第二层，SQL解析与执行计划生成。 MySQL收到一条SQL后，需要做词法解析、语法解析、语义检查、优化器生成执行计划。这一套动作的CPU消耗是固定的，单条插入1万次就要重复1万遍，而批量插入只需要执行一遍。

第三层，事务提交与日志落盘。 这是很多人忽略的关键点。InnoDB默认情况下，每次事务提交都要把redo log刷入磁盘，同时binlog也要落盘。一次fsync的系统调用，机械硬盘上可能耗时5到10毫秒，SSD上也需要1毫秒左右。如果你用单条插入并且每条一个事务，10万条数据意味着10万次fsync——这就是为什么单条插入无论如何都快不起来。

第四层，索引维护与数据页操作。 每插入一条记录，InnoDB都要定位到对应的聚簇索引页，在页内找到插入位置，维护二级索引，必要时触发页分裂。批量插入在同一个事务里，很多页操作可以重复利用缓存，减少物理I/O次数。

理解了这四层，你就能明白一个基本事实：批量插入性能提升的核心不是“SQL变短了”，而是减少了无效的工作重复。所以真正的问题不是“一次插多少条”，而是“在哪些资源的约束下，一次插多少条性价比最高”。

2. 把几种“批量插入”方案摆在一起对比

在动手做主路分析之前，先盘一下市面上常见的几种插入方式，包括它们的实现原理和第一个性能瓶颈。

先别急着选。每一种方案在不同的数据量级、并发模型、机器规格下，表现完全不同。下面逐个拆开。

2.1 单条循环为什么一定是错的

单条循环插入不是“慢”，是慢得不可理喻。我做过一个基准测试：向一张8个字段的简单业务表插入10万条数据，单条循环模式耗时大约427秒。而换成每批500条的VALUES拼接模式，同样的数据量只要7.8秒。两个数字之间差了将近55倍。

这里面最大的坑不在SQL执行本身，而在事务提交。很多人的代码长这样：

code复制Connection conn = dataSource.getConnection();
conn.setAutoCommit(true);   // 默认就是true
for (int i = 0; i < 100000; i++) {
    String sql = "insert into t_order (...) values (...)"
    statement.executeUpdate(sql);
}

自动提交模式下，每条insert都是一次完整的事务，InnoDB的redo log刷盘、binlog的sync操作都会被执行一轮。传统机械硬盘上，一次fsync耗时要5到10毫秒，这还不包括行锁获取、索引更新、binlog event写入。10万次循环，光事务提交的固定开销就把时间吃干净了。

2.2 拼接超长SQL：为什么通常会失败

把1万条记录的VALUES拼进一条SQ