批量INSERT应打包100–2000行进单事务提交，性能可提升几十至百倍；因频繁commit导致重复fsync、锁开销与SQL解析，远超写数据本身耗时。
直接结论：别让每条INSERT都触发一次commit，把100–2000行打包进一个事务再提交，性能通常能提升几十到上百倍。
为什么频繁提交会让INSERT变慢
MySQL默认autocommit=1，意味着每条INSERT语句都会独立开启、执行、刷日志（innodb_flush_log_at_trx_commit=1）、落盘、释放锁。10万条数据 = 10万次fsync、10万次锁获取/释放、10万次SQL解析。这些开销远超实际写数据本身。
常见错误现象包括：
- 插入1万行耗时超过30秒，而同样数据用批量事务1秒内完成
- 数据库CPU和I/O持续飙高，其他查询明显变慢或超时
- 出现
Lock wait timeout exceeded或Deadlock found报错
怎么设置合理的批量大小
没有固定“最优值”，关键看单行数据长度和业务容错能力。目标是让单个事务既不过小（浪费提交开销），也不过大（锁太久、回滚代价高、主从延迟突增）。
- 平均行长 ≤ 200 字节 → 每批 2000 行较安全（≈400KB，远低于默认
max_allowed_packet=4MB） - 含TEXT/BLOB字段或行长大于1KB → 建议每批 100–500 行
- 业务要求“失败不影响已成功批次” → 按主键范围分片（如
WHERE id BETWEEN 10001 AND 12000），比纯按行数更易定位问题 - 避免拼接超长字符串再执行——应用层应分批构造
INSERT INTO t VALUES (),(),...，而非攒成一条巨长SQL
必须配合的配置与操作
只改批量大小不够，还得关掉自动提交、调低日志刷盘强度，并注意索引影响：
- 务必在批量前执行
SET autocommit = 0或显式写START TRANSACTION，否则INSERT仍会各自提交 - 临时调整
innodb_flush_log_at_trx_commit：开发/导入环境可设为2（日志写OS缓存，不强制刷盘），但生产环境慎用；设为0风险极高，不推荐 - 导入前可
SET unique_checks = 0和SET foreign_key_checks = 0，导入完再恢复——但需确保数据本身无重复/外键违规，否则静默丢数据 - 确认表有显式主键：无主键时InnoDB会建隐藏聚簇索引，批量写入更容易争用页锁
LOAD DATA INFILE 是更快的替代方案
当数据已在本地文件（如CSV）中，LOAD DATA INFILE 比任何INSERT批量都快5–20倍，因为它绕过SQL解析层，直通存储引擎。
- 先检查服务端是否允许：
SHOW GLOBAL VARIABLES LIKE 'local_infile'，若为OFF，需SET GLOBAL local_infile = ON（需SUPER权限） - 客户端连接时也要启用，例如MySQL命令行加
--local-infile=1，Python的pymysql需传local_infile=True - 字段分隔符、行结束符必须严格匹配文件内容，否则会跳过错误行且不报错；导入前务必用小样本测试，并查
SHOW WARNINGS - 它不走事务机制，无法ROLLBACK，失败时只能重跑或手动清理，适合离线导入场景
真正容易被忽略的是事务粒度和监控联动：别追求“全量成功”，而要每批提交后立刻查 SELECT ROW_COUNT()，确认实际插入行数是否符合预期——INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 可能悄悄过滤掉部分数据，不检查就等于埋雷。
