单条INSERT循环慢的根源是每行触发完整事务流程（解析、加锁、写log、刷盘、释放锁、网络往返），10万次即10万次I/O和日志落盘；必须关闭autocommit、配合多值INSERT与显式事务（BEGIN/COMMIT），单批控制在1000–5000行，并调大max_allowed_packet和innodb_buffer_pool_size。
单条INSERT循环为什么慢得离谱
不是数据量大本身慢，而是每条INSERT都触发一次完整事务流程：SQL解析、加锁、写redo log、刷盘、释放锁、网络往返。10万次就是10万次I/O和日志落盘，哪怕每次只花5ms，总耗时也接近8分钟。
常见错误现象：SHOW VARIABLES LIKE 'autocommit';返回ON，但代码里没关；用ORM的saveAll()却没开驱动层批处理；插入前没查max_allowed_packet，结果中途报Packets larger than max_allowed_packet are not allowed。
- MySQL默认
autocommit = 1，每条语句都是独立事务 - ORM如MyBatis默认仍是逐条执行，除非显式配置
rewriteBatchedStatements=true并使用ExecutorType.BATCH - 网络延迟叠加严重——应用与DB不在一台机器时，10万次往返可能吃掉30%以上耗时
必须配事务的多值INSERT才真有效
把1000行塞进一个INSERT INTO t VALUES (...), (...), ...只是第一步。如果没关自动提交，MySQL照样每行刷一次log——语法批量了，事务没批量，白优化。
正确做法分三步：SET autocommit = 0 → 执行多值INSERT → COMMIT。或者用BEGIN; ... ; COMMIT;更清晰。
- 忘写
COMMIT会导致连接挂起、表锁住、后续查询全阻塞 - 事务太大（比如50万行）可能撑爆
innodb_log_file_size或undo空间，建议单批控制在1000–5000行 - PostgreSQL必须用
BEGIN; ... ; COMMIT;，不能依赖隐式事务；SQLite推荐BEGIN IMMEDIATE;避免写冲突
索引和约束不关，批量就退化成逐行
每插一行就校验外键、更新二级索引、跑触发器，等于把批量操作硬生生掰回单行节奏。InnoDB上DISABLE KEYS对MyISAM有效，但对InnoDB无效——别信过时教程。
真正有效的做法：
- MySQL：执行
SET FOREIGN_KEY_CHECKS = 0;+ALTER TABLE t DROP INDEX idx_name;（导入后再重建） - PostgreSQL：用
SET CONSTRAINTS ALL DEFERRED;延迟校验，或建表时加NOT VALID约束，导入后VALIDATE CONSTRAINT - SQL Server：
ALTER INDEX IX_Name ON t DISABLE;，但UNIQUE/CHECK约束无法禁用，只能临时删掉
注意：操作完必须恢复并验证数据一致性，否则后续INSERT可能被拒绝，查询可能返回错误结果。
别依赖ORM默认行为，原生接口才是关键路径
JPA的saveAll()、MyBatis的<foreach>默认仍是N次单条执行。真正提速靠的是JDBC驱动层的原生能力，不是框架封装。
实操要点：
- MySQL连接串必须加
rewriteBatchedStatements=true，否则addBatch()会被忽略 - Java里要用
PreparedStatement.addBatch()+executeBatch()，且batch size设为1000左右（不是越大越好） - 超大批量（百万级）直接走
LOAD DATA INFILE或COPY（PostgreSQL），比任何SQL插入都快一个数量级
容易被忽略的点：max_allowed_packet决定单条语句最大长度，不是行数；innodb_buffer_pool_size太小会导致索引页频繁换入换出，批量插入时反而更慢——调大它比调批大小更立竿见影。
