单次批量插入无全局最优行数，关键取决于max_allowed_packet字节限制、innodb_log_buffer_size事务日志缓冲能力及二级索引维护成本；需按字段实际长度动态估算，并结合rewriteBatchedStatements参数与事务分批控制。
单次批量插入多少行最合适？看这三点硬指标
没有全局最优的固定行数，真正起决定作用的是三个数据库侧的硬性限制：网络包大小、事务日志缓冲区、索引维护成本。盲目套用“1000行”或“5000行”反而容易触发错误或性能拐点。
-
max_allowed_packet决定单条SQL能多长——它不是行数限制，而是字节上限。默认 64MB（134217728），但你拼出的 SQL 字符串（含括号、逗号、引号、转义）会快速吃掉这个空间。一行VALUES (1, 'abc', '2026-10-14')在 UTF8MB4 下轻松占 30–50 字节，1000 行就约 50KB；若字段含长文本或 JSON，200 行就可能超限。 -
innodb_log_buffer_size（默认67108864，即 64MB）影响事务内 redo 日志缓存能力。超过该值，InnoDB 会强制刷盘一次，打断写入流水线。实测中，当单批次数据导致 redo 日志写入量接近此值时，吞吐量明显下降。 - 二级索引数量和字段长度直接影响 B+ 树分裂频率。比如对一个有 5 个二级索引的表插入 UUID 主键，即使只插 100 行，也可能引发多次页分裂和磁盘随机写；而顺序自增主键 + 无二级索引时，插 5000 行也几乎无感。
如何动态估算安全批次大小？用 SQL 查、用数据算
别靠猜，直接查配置 + 算单行平均体积。这是最稳的起点。
- 先查关键参数：
SHOW VARIABLES LIKE 'max_allowed_packet';和SHOW VARIABLES LIKE 'innodb_log_buffer_size'; - 用实际字段结构估算单行字符长度：比如
INT占 11 字符（-2147483648 最长）、VARCHAR(255)按业务预期填充率取均值（如 30% → 约 76 字符），加上逗号、括号、引号，加总后乘以安全系数 0.7（留缓冲）。 - 例如：字段为
(id INT, name VARCHAR(64), content TEXT)，content 平均 200 字符，则单行约 250 字节 →134217728 × 0.7 ÷ 250 ≈ 375,000行 —— 但这远超innodb_log_buffer_size承载力，此时应以 64MB / 250 ≈ 26万行为理论极限，再砍半取 10–15 万作为首试值。
JDBC 或 Python pymysql 中怎么分批才不翻车？
代码里硬写 for i in range(0, len(data), 1000) 是常见误区。真正的分批逻辑必须绑定到单条 SQL 的字节长度，而非行数。
- Python 示例（pymysql）：
def batch_insert(cursor, table, columns, rows, max_sql_len=1_000_000):<br> batch = []<br> for row in rows:<br> sql_part = f"({', '.join(map(repr, row))})"<br> if len(sql_part) + sum(len(b) for b in batch) > max_sql_len:<br> cursor.execute(f"INSERT INTO {table} ({', '.join(columns)}) VALUES " + ", ".join(batch))<br> batch = []<br> batch.append(sql_part)<br> if batch:<br> cursor.execute(f"INSERT INTO {table} ({', '.join(columns)}) VALUES " + ", ".join(batch)) - JDBC 注意开启
rewriteBatchedStatements=true（如jdbc:mysql://host/db?rewriteBatchedStatements=true），否则addBatch()只是攒语句，驱动不会自动合并成多值 INSERT；没开这个参数，即使写了批处理，仍走 N 次网络往返。 - 永远在事务外控制批次：BEGIN → 插一批 → COMMIT → 下一批。不要把几十万行塞进一个事务，否则锁持有时间过长，且一旦失败回滚代价巨大。
LOAD DATA INFILE 是不是一定更快？看数据来源
它快，但快得有条件。不是所有场景都能用，强行用反而绕路。
- 适用：原始数据已在服务器本地文件（
/var/lib/mysql-files/data.csv）或 MySQL 支持的可访问路径；格式规整（无嵌套 JSON、无需运行时转换）；允许临时关闭secure_file_priv限制。 - 不适用：数据来自 HTTP API、Kafka 流、内存 List；需要插入前做字段清洗、脱敏、关联查询；表有触发器（
LOAD DATA不触发）；或你无法登录数据库服务器改配置。 - 性能对比真实值：同一批 87 万日志记录，Python 循环 INSERT 耗 10 小时，多值 + 事务优化后缩至 3 分钟，而
LOAD DATA INFILE仅需 22 秒——但前提是日志已预处理成 CSV 且无非法字符。中间省下的 2 分多钟，全是客户端解析、网络传输、驱动序列化的开销。
实际调优中最容易被跳过的一步，是验证每批次执行后的 SHOW ENGINE INNODB STATUS\G 里有没有 “log sequence number 增长突变” 或 “pending log writes”。这些信号比插入耗时更早暴露缓冲区瓶颈。
