bulk_insert_buffer_size对LOAD DATA INFILE基本无效，它仅在MyISAM引擎执行INSERT...SELECT等操作时生效；InnoDB下该参数纯属存在但无用，真正影响LOAD DATA性能的是innodb_buffer_pool_size、innodb_log_file_size、磁盘I/O及binlog配置。
bulk_insert_buffer_size 对 LOAD DATA INFILE **基本无效**——这是最容易踩的坑。
MySQL 官方文档和源码逻辑都明确：该变量仅在 MyISAM 引擎执行 INSERT ... SELECT、REPLACE ... SELECT 或 CREATE TABLE ... SELECT 时被用于加速批量插入；而 LOAD DATA INFILE（无论 InnoDB 还是 MyISAM）**完全不走 bulk insert buffer 路径**，它绕过 SQL 解析器，直接构造记录并写入页缓冲区，bulk_insert_buffer_size 根本不会被分配或使用。
所以迁移后变慢，别急着调这个参数——它不是瓶颈，也改不动性能。
真正影响 LOAD DATA 速度的三个关键点
迁移常伴随环境变更（如从物理机到云 RDS、从 SSD 到低配云盘、从 MySQL 5.7 升级到 8.0），以下才是实际起作用的环节：
-
innodb_buffer_pool_size过小 → 索引页频繁换入换出，重建索引阶段卡顿明显 -
innodb_log_file_size偏小 → 导入中 checkpoint 频繁触发，redo log 切换+刷盘成为 I/O 瓶颈 - 磁盘 I/O 能力下降 → 迁移后存储类型变更（如 HDD 替代 NVMe）、IOPS 限制（云数据库默认配额）、日志与数据文件共盘争抢
为什么你看到 bulk_insert_buffer_size 被提到了？
混淆主要来自两处：
- 部分博客把 MyISAM 的
DISABLE KEYS优化误套用到 InnoDB，并错误归因于bulk_insert_buffer_size - 某些压测脚本混用了
INSERT INTO ... SELECT和LOAD DATA，没隔离变量作用域，导致结论污染 - 执行
SELECT @@global.bulk_insert_buffer_size能读出值，不代表它此刻生效——InnoDB 下该变量纯属“存在但无用”
迁移后导入变慢，优先检查这四件事
别调 bulk_insert_buffer_size，做这些更实在：
- 确认表引擎：
SHOW CREATE TABLE your_table→ 必须是ENGINE=InnoDB；MyISAM 在现代迁移场景中已基本淘汰，且其DISABLE KEYS也不依赖该 buffer - 查当前日志配置：
SELECT @@innodb_log_file_size, @@innodb_log_buffer_size→ 小于 1G 的innodb_log_file_size在亿级导入中必然拖慢 - 看磁盘真实吞吐：
iostat -x 1观察%util和await→ 若%util ≈ 100%且await > 20ms，说明 I/O 已饱和 - 检查是否意外开启了 binlog：
SELECT @@sql_log_bin→ 云数据库常默认开启，且sync_binlog=1会强制每事务刷盘，大幅拉低速度
真正要动的缓冲区是 innodb_buffer_pool_size 和 innodb_log_buffer_size，而最关键的往往是磁盘延迟和日志文件大小。调错参数不仅白费功夫，还可能掩盖真实的 I/O 或配置漂移问题。
