MySQL批量插入非标准SQL集合操作，而是单条INSERT的多行扩展；常用写法有VALUES多值、SELECT导入、冲突处理三种；性能受max_allowed_packet、binlog格式、驱动配置等影响。
MySQL批量插入不是标准SQL集合操作，但效果接近
严格来说，INSERT INTO ... VALUES (...), (...), (...) 不属于 SQL 标准定义的「集合操作」（如 UNION、INTERSECT、EXCEPT），它只是单条 INSERT 语句的多行值扩展语法。但因一次网络往返写入多行，实际行为上具备集合式吞吐特征。
关键区别在于：集合操作作用于查询结果集之间，而批量插入作用于待写入的数据元组集合——目标不同，语义不同，优化路径也不同。
批量插入的三种常见写法及适用场景
实际开发中容易混淆写法，导致性能或语义错误：
-
INSERT INTO t(a,b) VALUES (1,2), (3,4), (5,6)：最常用，上限受max_allowed_packet限制（默认约 4MB），适合单次几百到几千行 -
INSERT INTO t(a,b) SELECT a,b FROM temp_staging：真正基于集合的写入，适合从临时表/CTE导入，可配合WHERE过滤，事务开销低 -
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE：带冲突处理的批量写入，注意ON DUPLICATE KEY UPDATE中的VALUES(col)引用的是当前这一行的待插入值，不是表中旧值
容易被忽略的性能与一致性陷阱
批量插入看似简单，但几个底层细节常引发线上问题：
- 自增主键在批量插入中会预分配连续 ID，即使部分行因唯一键冲突被跳过，ID 也不会回退——导致 ID 空洞不可控
- 事务日志（redo log）按批刷盘，但 binlog 默认是语句级（STATEMENT）时，
INSERT ... VALUES (...),(...)整体记为一条事件；若改用 ROW 格式，则每行生成独立事件，复制延迟和空间占用显著增加 - 如果批量中某一行违反约束（如
NOT NULL），整条语句失败（除非启用了STRICT_TRANS_TABLES模式外的宽松模式，但不推荐依赖） -
LOAD DATA INFILE虽不属于 SQL 插入，却是真正的「集合导入」：绕过 SQL 解析层，速度最快，但要求文件在 MySQL 服务端本地，且权限配置复杂
Python/Java 应用中批量插入的实际控制点
ORM 或连接器封装常隐藏关键参数，需主动干预：
- MySQL Connector/Python 的
executemany()默认把多行拆成多个单行INSERT，必须显式传入元组列表并启用multi=True才生成真正的批量语法 - JDBC 的
addBatch()+executeBatch()行为取决于驱动版本和rewriteBatchedStatements=true参数：设为true后，驱动才把多条单行INSERT重写为一条多值语句；否则仍是 N 次 round-trip - 无论用哪种方式，都要监控
innodb_buffer_pool_wait_free和Threads_created，批量过大可能触发频繁刷脏页或线程创建，反而降低吞吐
cursor.executemany(
"INSERT INTO users(name, age) VALUES (%s, %s)",
[("Alice", 25), ("Bob", 30), ("Charlie", 35)]
)
这行代码在未开启 multi=True 时，底层仍是三次独立执行；开启后才等价于一条三元组 INSERT。
真正影响写入效率的，从来不是“是不是集合操作”的标签，而是数据如何进入存储引擎缓冲区、日志怎么落盘、以及冲突时谁来决定跳过还是报错——这些细节藏在参数、驱动、语句形态的组合里，而不是语法分类中。
