单条insert语句受max_allowed_packet和sql解析开销双重限制，建议每批1000–2000行（约1–2mb），兼顾解析性能、锁竞争与复制延迟；超大批量易引发锁超时、redo log尖峰及从库延迟。
单条INSERT语句有长度和解析开销限制
MySQL 不是“越大批量越好”，INSERT INTO ... VALUES (...), (...), ... 这种写法本质是一条 SQL 语句，它受两个硬性约束：一是 max_allowed_packet（默认 64MB），二是 SQL 解析器的内存与时间成本。当 VALUES 列表超过几万项时，MySQL 解析可能变慢，甚至直接报错 Packets larger than max_allowed_packet are not allowed。
- 实测中，1000–2000 行/条是较稳妥的区间，兼顾网络包大小、解析速度与事务粒度
- 若每行平均 500 字节，2000 行 ≈ 1MB，远低于默认 64MB 上限，但已足够触发明显解析延迟
- 超长语句在高并发下还可能卡住 query cache（如启用）或影响 query plan 缓存命中
事务过大导致锁竞争和 WAL 压力飙升
一次插入 10 万行 = 一个事务持有表级/行级锁长达数秒，期间其他 DML 操作会被阻塞；同时 InnoDB 的 redo log 必须把这 10 万行变更一次性刷盘（尤其当 innodb_flush_log_at_trx_commit=1 时），I/O 尖峰极易拖垮整个实例。
- 锁等待超时常见错误：
Lock wait timeout exceeded; try restarting transaction - redo log 写入不是线性叠加，而是按 page 批次 flush，大事务会迫使更多 dirty page 提前刷出，干扰正常 checkpoint 流程
- 主从复制中，大事务在 binlog 中表现为单个 event，从库回放时无法并行，造成严重延迟
分批提交能平衡性能与稳定性
分批不是妥协，而是对 MySQL 底层机制的尊重——它让事务粒度、日志刷盘、锁释放、网络传输全部落在合理区间内。500–1000 行/批是多年生产验证过的“甜点区”。
- 每批用显式事务包裹：
BEGIN; INSERT ...; COMMIT;，避免隐式自动提交放大开销 - 应用层控制批次节奏，比如 Python 用
executemany()配合chunksize=1000，Java MyBatis 用<foreach></foreach>+ExecutorType.BATCH - 注意：不要盲目调大
innodb_log_file_size来撑大事务，它影响的是 recovery 时间，不解决锁和复制延迟问题
LOAD DATA INFILE 是更重的替代方案
当数据源是本地文件且格式规整（如 CSV），LOAD DATA INFILE 比任何 INSERT 批量都快一个数量级，因为它绕过 SQL 解析层，直接走存储引擎接口。但它不适用于动态生成的数据或需要业务逻辑校验的场景。
- 必须确保 MySQL 服务端能访问该文件路径（不是客户端）
- 字段分隔符、NULL 处理、字符集需显式指定，否则易出现静默截断或乱码
- 执行时仍会加表锁（MyISAM）或行锁（InnoDB），但持续时间远短于等量 INSERT
Waiting for table metadata lock。这些信号比教科书上的“1000 行”更有说服力。
