bulk_insert_buffer_size对InnoDB完全无效，仅MyISAM批量插入（如INSERT...VALUES、INSERT SELECT）有效；InnoDB应优化innodb_buffer_pool_size、innodb_log_file_size、关闭unique_checks等参数。
bulk_insert_buffer_size 对 InnoDB 表完全无效
如果你用的是默认的 InnoDB 引擎（99% 的生产环境都是），调 bulk_insert_buffer_size 不会带来任何插入速度提升。这个参数只被 MyISAM 引擎用于缓存键值，InnoDB 根本不读它——哪怕你设成 2G，SHOW STATUS LIKE 'Innodb_rows_inserted' 增长曲线也不会变陡。
常见翻车点：
- 在 RDS 或容器 MySQL 中执行
SET GLOBAL bulk_insert_buffer_size = 512*1024*1024，命令不报错，但后续LOAD DATA INFILE或INSERT ... SELECT完全不受影响 - 误以为“bulk”字样就管所有批量操作，实际上它和
LOAD DATA INFILE无关，也和事务内的多行INSERT无关 - 把
bulk_insert_buffer_size和innodb_buffer_pool_size、sort_buffer_size混淆，后者才真正影响 InnoDB 批量写入性能
MyISAM 场景下怎么安全启用 bulk_insert_buffer_size
仅当确认表是 MyISAM 且执行的是单语句多值插入（如 INSERT INTO t VALUES (1),(2),(3)）时，该参数才起作用。必须配合 DISABLE KEYS 使用，否则缓冲区形同虚设。
实操要点：
- 先执行
ALTER TABLE t DISABLE KEYS，再插入；完成后必须执行ALTER TABLE t ENABLE KEYS，否则索引损坏、查询失效 - 会话级设置更安全：
SET SESSION bulk_insert_buffer_size = 67108864（64MB），避免全局污染其他连接 - 不要盲目调大：超过 128MB 后收益急剧下降，且可能挤占其他线程内存
- MySQL 8.0+ 中
MyISAM已基本弃用，不建议新项目使用
InnoDB 批量插入真正该调什么
想让 InnoDB 插得快，核心是控制事务粒度、减少日志刷盘、绕过 SQL 解析层。这些动作比瞎调 bulk_insert_buffer_size 有效十倍。
关键操作：
- 用
LOAD DATA INFILE替代拼接的INSERT：它直写存储引擎，快 5–10 倍，且天然跳过 SQL 层校验 - 导入前关两检查：
SET UNIQUE_CHECKS = 0和SET FOREIGN_KEY_CHECKS = 0，导入完立即恢复 - 临时调低日志刷盘强度：
SET GLOBAL innodb_flush_log_at_trx_commit = 2（注意：断电可能丢 1 秒数据） - 增大
innodb_log_file_size（需重启）：设为 1G～2G，减少 checkpoint 频率；太小会导致 LOAD DATA 卡在日志刷写上 - 确保
innodb_buffer_pool_size足够大：至少物理内存的 50%，否则大量脏页刷盘会拖垮导入速度
为什么很多人调了 bulk_insert_buffer_size 还是慢
根本原因不是参数没生效，而是压根没走它生效的路径。比如：
- ORM 框架逐条
INSERT+ 自动COMMIT：每条都开启新事务，bulk_insert_buffer_size完全不触发 - 主键乱序插入（如 UUID 或随机 ID）：InnoDB 无法做顺序页填充，强制页分裂，缓冲区无意义
- 目标表有大量二级索引：索引维护开销远高于缓冲区能省下的时间，应先删索引，导入完重建
- 云厂商限制：阿里云 RDS 等早期版本直接禁用该变量，
SET GLOBAL成功但实际不生效
最常被忽略的一点：没确认引擎类型就动手调参。执行 SHOW CREATE TABLE your_table 看第一行 ENGINE=InnoDB 还是 ENGINE=MyISAM，这一步跳过，后面全白忙。
