MySQL单条INSERT多VALUES可显著提升性能，因其仅解析一次SQL、复用执行计划、减少网络往返与日志刷盘，推荐每批1000–5000行并显式事务包裹。
单条INSERT多VALUES减少SQL解析和网络往返
MySQL对每条独立的INSERT语句都要走一遍完整流程：网络接收 → 语法解析 → 权限校验 → 执行计划生成 → 存储引擎调用 → 日志写入 → 提交。而INSERT INTO t (a,b) VALUES (1,2), (3,4), (5,6)这种写法，整个语句只被解析一次，后续所有行都复用同一执行计划。
常见错误现象：在应用层用循环拼接1000次INSERT INTO t VALUES (x)发给MySQL，实际产生1000次TCP包、1000次parse、1000次commit——哪怕连接复用也逃不掉这些开销。
实操建议：
- 显式指定列名，避免表结构变更后因字段数错位导致
Column count doesn't match value count - 控制单条语句的
VALUES组数在1000–5000之间，防止触发max_allowed_packet限制（默认4MB，可查SHOW VARIABLES LIKE 'max_allowed_packet'） - 如果用ORM或MyBatis，确认其批量插入是否真生成了多
VALUES语法，而非后台模拟循环（比如MyBatis的<foreach></foreach>必须配合separator=","才能生效）
多VALUES共享事务生命周期，锁管理更高效
单行循环插入时，每条INSERT默认是独立事务（autocommit=1），InnoDB为每一行单独加X锁、插入完立刻释放，1000次就是1000次加锁/释放；而多VALUES是在一个语句内完成，InnoDB会预判所有行的索引位置，只对涉及的索引页和间隙加锁，且锁持续到语句结束。
容易踩的坑：
- 有唯一索引时，单行插入会重复做N次B+树查找和冲突检查；多
VALUES只做一次合并判定，实测1万行插入，索引查找次数从1.2万次降到300次以内 - 不加显式事务时，多
VALUES语句仍是自动提交，锁在语句结束就释放；若需更长锁持有时间（如避免中间态被其他DML干扰），应包在BEGIN; ... COMMIT;里 - 批大小超过5000行可能触发锁升级（如行锁→页锁），尤其在高并发更新同一范围数据时，反而增加阻塞风险
日志写入和磁盘IO更省
每次事务提交都要刷redo log和binlog，单行循环意味着N次fsync；而多VALUES在同一个事务中，redo log可以批量合并记录，binlog也只写一次逻辑事件（Format Description + Query Event），大幅降低磁盘IO压力。
性能影响明显点：
- 在机械硬盘或高延迟云盘上，IO差异直接反映为耗时差距——插入10万行，单行循环可能卡在日志刷盘上，而批量插入稳定在秒级
-
innodb_flush_log_at_trx_commit=1时该优势最显著；设为2或0会削弱但不消除差异 - 注意
bulk_insert_buffer_size仅对MyISAM有效，InnoDB无需调这个参数
为什么不是越多VALUES越好？
看似把10万行塞进一条INSERT最省事，但实际会翻车。MySQL解析超长SQL本身吃CPU，网络传输可能被中间设备截断，内存分配也可能失败。
关键限制条件：
-
max_allowed_packet硬上限：所有VALUES文本长度（含逗号、括号、转义字符）不能超此值，否则报错Packets larger than max_allowed_packet are not allowed - 语句太长会导致查询缓存（如启用）失效率飙升，且难以调试——某一行出错，整条语句回滚，错误定位困难
- 推荐分批策略：按1000–5000行为单位切分，每批显式用
BEGIN; INSERT ... ; COMMIT;包裹，既控锁粒度，又保错误隔离
真正难处理的从来不是“怎么写”，而是“写多少”和“什么时候提交”——这两个数字没调准，再规范的语法也救不了性能。
