bulk_insert_buffer_size对innodb表完全无效，仅myisam引擎在disable keys配合下单语句多值插入时生效；innodb应优化innodb_buffer_pool_size、innodb_log_file_size、set unique_checks=0及使用load data infile。
bulk_insert_buffer_size 对 InnoDB 表根本不起作用
如果你用的是默认的 InnoDB 引擎（99% 的生产环境都是），调大 bulk_insert_buffer_size 不会带来任何插入速度提升。这个参数只被 MyISAM 引擎读取，用于缓存键值（KEYS）写入；InnoDB 完全不走这套逻辑，它依赖 innodb_buffer_pool_size、redo log 刷写策略和事务粒度来控制写性能。
常见翻车点：
- 执行
SET GLOBAL bulk_insert_buffer_size = 512M后跑LOAD DATA INFILE或INSERT ... SELECT，发现毫无变化 —— 因为LOAD DATA INFILE绕过 SQL 层，INSERT ... SELECT在InnoDB下也不触发该缓冲区 - 在 RDS 或容器化 MySQL 中强行设参，结果被权限拦截或静默忽略，还误以为是配置没生效
- 把
bulk_insert_buffer_size和sort_buffer_size、read_buffer_size混淆，后两者影响的是排序和扫描，不是批量插入
MyISAM 场景下怎么安全启用 bulk_insert_buffer_size
只有当你明确确认表引擎是 MyISAM，且使用的是单语句多值插入（如 INSERT INTO t VALUES (1),(2),(3)）时，这个参数才可能生效。
必须配合以下操作，否则缓冲区形同虚设：
- 插入前执行
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 插得快，重点不在 bulk_insert_buffer_size，而在绕过事务和日志瓶颈。
导入前必做几件事：
- 关唯一校验：
SET UNIQUE_CHECKS = 0；导入完再开回= 1 - 关外键检查：
SET FOREIGN_KEY_CHECKS = 0 - 关自动提交：
SET AUTOCOMMIT = 0，每 1w～10w 行手动COMMIT - 改日志刷盘策略：
SET innodb_flush_log_at_trx_commit = 2（导入阶段临时用，断电可能丢 1 秒数据） - 优先用
LOAD DATA INFILE，它比拼接INSERT快 5–10 倍，且天然跳过 SQL 解析层
配套配置项（需重启或动态 SET）：
-
innodb_log_file_size至少设为 1G 起步，减少 checkpoint 频率 -
innodb_buffer_pool_size建议设为物理内存的 50%–75%，确保脏页有足够空间暂存 - 导入期间可临时关
innodb_doublewrite = OFF（仅限有 UPS 或能接受崩溃风险的场景）
为什么你看到的“调 bulk_insert_buffer_size 加速”教程都失效了
因为绝大多数这类文章没区分存储引擎，也没说明适用前提。它们往往基于老旧的 MyISAM 环境或测试用例，而当前主流 MySQL 默认全是 InnoDB，且 LOAD DATA INFILE 是事实标准。
最容易被忽略的一点是：参数是否生效，取决于「引擎 + 插入方式 + 事务控制」三者是否同时匹配。哪怕你把 bulk_insert_buffer_size 设到 1G，只要表是 InnoDB、SQL 是逐条 INSERT、又开着 AUTOCOMMIT=1，那它就只是个躺在变量表里的数字，从不参与任何执行路径。
