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。
真正影响写入效率的，从来不是“是不是集合操作”的标签，而是数据如何进入存储引擎缓冲区、日志怎么落盘、以及冲突时谁来决定跳过还是报错——这些细节藏在参数、驱动、语句形态的组合里，而不是语法分类中。
