多行insert能减少网络传输开销，因其将n次sql执行压缩为1次tcp往返，使网络开销从o(n)降至o(1)；实际行数受max_allowed_packet限制，建议每批1000–5000行，并配合事务控制与索引优化提升性能。
为什么多行INSERT能减少网络传输开销
单条 INSERT INTO t(a,b) VALUES (1,2) 每执行一次，就要走完整 TCP 往返：客户端发 SQL → 服务端解析/执行 → 返回 OK 包。1000 条就等于 1000 次 RTT。而 INSERT INTO t(a,b) VALUES (1,2), (3,4), (5,6) 把这 1000 行塞进一条语句里，只触发 1 次往返——网络开销直接从 O(N) 降到 O(1)，跨机房或高延迟链路下差距尤其明显。
VALUES 后面最多写多少行才安全
不能只看“想插多少”，得看 max_allowed_packet 实际限制。默认值通常是 4MB，但实际可用空间还要减去 SQL 模板（如 INSERT INTO ... VALUES ）和逗号、括号等符号开销。假设每行平均占 200 字节，理论极限约 2 万行，但生产环境不建议这么激进：
- 每批控制在
1000–5000行之间，兼顾吞吐与稳定性 - 字段越多、内容越长（比如含
TEXT或 JSON），单行体积越大，应相应减少行数 - 超过
max_allowed_packet会报错Packet too large，不是慢，是直接失败 - 行数过多还可能触发
sort_buffer_size不足，被迫写磁盘临时表，反而拖慢
要不要加 START TRANSACTION 包裹多行INSERT
单条多值 INSERT 本身就是一个原子事务，不加 START TRANSACTION 也比 N 条单行快。但如果你要分批插入几万甚至百万行，把多个多值 INSERT 语句包进一个显式事务里，能进一步省掉每条语句的事务启动/提交固定开销：
- 默认
autocommit = ON时，每个INSERT都会刷一次 redo log 和 binlog - 手动
START TRANSACTION+ 多个INSERT+COMMIT，只刷 1 次日志 - 注意：事务太大（比如一次性提交 100 万行）会延长锁持有时间，增加阻塞风险
- 推荐每
COMMIT控制在 1 万行以内，平衡性能与并发安全
容易被忽略的隐性瓶颈：索引与唯一检查
很多人只盯着 SQL 写法和事务，却忘了 InnoDB 在批量插入时仍要逐行做唯一索引校验、B+ 树页分裂。这些操作不会因为“一条语句插多行”就跳过：
- 主键或唯一索引字段若乱序（比如按随机 ID 插入），会导致频繁页分裂，性能断崖下跌
- 可提前用
SET UNIQUE_CHECKS=0临时关闭唯一性检查，导入完再设回1 - 外键约束同理：
SET foreign_key_checks = 0能显著提速，但务必确认数据一致性 - 如果源数据能排序（比如按主键升序），优先排好再批量插入，B+ 树追加更高效
SHOW ENGINE INNODB STATUS 和慢日志，而不是只数 INSERT 语句写了几个括号。
