单条INSERT比批量VALUES慢一个数量级，因前者每次需完整解析、优化、日志刷盘，后者复用执行计划且仅一次日志写入；实测100行批量耗时8–12ms，单行则超800ms。
为什么单条INSERT比批量VALUES慢一个数量级
因为每次 INSERT INTO t VALUES (...) 都要走完整解析、优化、事务日志刷盘流程；而 INSERT INTO t VALUES (...), (...), (...) 复用同一套执行计划，只触发一次日志写入和索引更新。实测在普通SSD+InnoDB下，100行批量插入耗时约 8–12ms，拆成100次单行插入则稳定在 800ms+。
关键限制不在MySQL本身，而在客户端网络往返（RTT）和服务器端的 max_allowed_packet。默认值通常为 4MB，意味着单条语句最多塞约 10 万个小字段行（按每行 40 字节估算），但实际建议控制在 1k–5k 行之间——再大容易触发超时或内存抖动。
VALUES列表长度不是越长越好：平衡吞吐与稳定性
盲目堆高单条语句的 VALUES 数量，反而会因锁持有时间变长、undo日志膨胀、主从复制延迟加剧而降低整体吞吐。线上压测表明：在 2核4G MySQL 5.7 实例上，每批 1000 行时 QPS 稳定在 12,000+；拉到 5000 行后，QPS 不升反降（跌至 9,500），且 innodb_row_lock_time_avg 上升 3 倍。
- 优先按业务逻辑分批：比如用户行为日志按 session_id 聚合，避免跨事务打散
- 避开大字段：含
TEXT或BLOB的行应单独批次处理，否则max_allowed_packet容易溢出 - 用
INSERT IGNORE或ON DUPLICATE KEY UPDATE替代先查后插，但注意后者会增加唯一索引扫描开销
绕过SQL拼接陷阱：用LOAD DATA INFILE还是PREPARE + EXECUTE？
手拼 VALUES (..),(..),.. 字符串极易出错：引号转义不全、NULL 写成字符串 'NULL'、时区/编码错位导致乱码插入。更稳的方式是：
-
LOAD DATA INFILE：吞吐最高（实测比批量VALUES快 30–50%），但要求文件在数据库服务器本地，且需FILE权限；生产环境常被禁用 -
PREPARE + EXECUTE：适合动态列数场景，例如 ETL 中字段名来自配置；但预编译无法复用跨批次的占位符结构，每批仍需重新PREPARE - 真正推荐的是「客户端组装 + 参数化批量绑定」：如 Python 的
executemany()（底层自动拆包为多值语句）、Go 的sqlx.NamedExec，它们既规避拼串风险，又保持协议层高效
别忽略 autocommit 和事务边界的影响
即使用了批量 VALUES，如果每条都单独提交（autocommit=1），性能照样崩。必须显式用 BEGIN/COMMIT 包裹多条批量语句——比如每 10 批（即 1 万行）提交一次，而非每批一提交。
同时确认 innodb_flush_log_at_trx_commit=1（强一致性必需），此时单次 COMMIT 触发一次 fsync；若设为 2，虽吞吐略升，但断电可能丢最后一秒事务，金融类系统慎用。
还有个隐藏坑：INSERT ... SELECT 语句即使带批量 VALUES，也会因子查询重执行导致性能跳变，这类场景应先 CREATE TEMPORARY TABLE 缓存中间结果。
