单条insert插入多行比多次单行insert快，因其仅执行一次sql解析、事务提交和日志写入，显著减少网络开销、cpu消耗及索引分裂；但受max_allowed_packet限制，建议每批1000–5000行，并配合事务包装与合理配置优化性能。

单条INSERT语句插入多行数据比多次执行INSERT快

因为MySQL对每条独立的INSERT语句都要走完整流程：网络传输 → SQL解析 → 事务开启 → 日志写入 → 索引更新 → 提交。而INSERT INTO t(a,b) VALUES (1,2), (3,4), (5,6)这种写法，只触发一次上述全流程。

• 网络开销从 N 次 RTT 降到 1 次，尤其跨机房或高延迟环境差异极明显
• 默认自动提交模式下，N 条单行插入 = N 次事务提交，每次都要刷 redo log 和 binlog；批量插入只刷 1 次
• SQL 解析和执行计划生成仅发生 1 次，避免重复消耗 CPU
• 索引 B+ 树的分裂与合并也更少——不是逐行插入时每条都可能触发页分裂，而是整体评估后一次性调整

VALUES后面逗号分隔的行数有实际限制

MySQL 默认限制单条语句最大长度为 max_allowed_packet（通常 4MB），超过会报错 Packet too large。实际能塞多少行，取决于每行数据长度 + SQL 模板开销。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 假设每行平均 200 字节，4MB 理论上限约 2 万行，但生产中建议控制在 1000–5000 行以内
• 行数过多会导致内存临时占用飙升，可能触发 sort_buffer_size 或 tmp_table_size 不足，降级为磁盘临时表
• InnoDB 对单个 INSERT 的锁持有时间变长，容易阻塞其他 DML，尤其在有唯一索引冲突检查时

不加事务包装的批量INSERT仍比逐条快，但加事务更稳

即使不显式写 START TRANSACTION，单条多值 INSERT 本身就是一个原子事务。但如果你要插入几千批数据，把多条批量语句包进一个事务里，能进一步省掉事务启动/提交的固定开销。

• 例如插入 10 万行：拆成 100 条批量语句（每条 1000 行）+ 外层 BEGIN; ... COMMIT;，比 100 条独立批量语句快 20%–40%
• 注意：事务太大（如单事务插 50 万行）会导致 undo log 膨胀、主从延迟加剧，甚至被 innodb_lock_wait_timeout 中断
• 出错时整批回滚是确定行为，无法跳过某几行失败数据——这点和逐条插入的“局部失败”逻辑完全不同

真正卡顿的地方往往不在SQL本身

当批量插入变慢，先别急着调优 SQL 写法。90% 的真实瓶颈在配套配置或表结构上。

• autocommit=1 且没包事务 → 每条批量语句仍是独立事务，失去“减少提交次数”的优势
• 目标表存在多个二级索引 → 每行数据都要更新所有索引，批量只是把这部分压力集中爆发，不如先 DROP INDEX，插完再建
• 没关 innodb_flush_log_at_trx_commit=1 → 强制每次事务提交都刷盘，批量意义大打折扣；测试环境可设为 2，生产权衡持久性后考虑 0
• 用 LOAD DATA INFILE 替代 INSERT 是更快路径，但它绕过 SQL 层，不走触发器、不校验外键，适用场景有限

批量插入不是“写得越长越好”，关键在平衡单次数据量、事务粒度、索引负担和系统配置。最容易被忽略的是：你以为在优化 INSERT，其实慢点早藏在 autocommit 或索引数量里了。