innodb_buffer_pool_size调小导致导入卡住，因缓冲池过小引发频繁磁盘读和lru淘汰，io成为瓶颈；应设为内存50%–75%，并配合调整unique_checks、foreign_key_checks、innodb_log_buffer_size等参数。
为什么 innodb_buffer_pool_size 调小了导入就卡住
MySQL 全量导入（比如 mysql ）本质是大量 INSERT + 事务日志刷盘，InnoDB 需频繁读写页、维护缓冲池链表、做 LRU 淘汰。如果 <code>innodb_buffer_pool_size 太小（比如默认 128MB），缓冲池很快被填满，导致大量物理磁盘读（从 ibdata 或表空间文件加载页）和频繁淘汰+重载，IO 成瓶颈。
实操建议：
- 导入前把
innodb_buffer_pool_size设为物理内存的 50%–75%，但别超 80%，留内存给 OS 缓存和 MySQL 其他结构（如sort_buffer_size） - 确认可用内存：用
free -h看available值，不是total - 动态调（5.7+）：
SET GLOBAL innodb_buffer_pool_size = 4294967296;（4GB），但注意该值必须是 1MB 的整数倍，且重启后失效；永久生效要改my.cnf - 别在导入中途调——可能触发 buffer pool 重建，反而中断导入
导入时还卡？检查这几个配套参数是否拖后腿
innodb_buffer_pool_size 单独调大效果有限，它和日志、刷脏、唯一检查等环节强耦合。常见配套参数不匹配，会让缓冲池“有劲使不出”。
实操建议：
- 关掉唯一性检查：
SET UNIQUE_CHECKS=0;，导入完再开；否则每行 INSERT 都查二级索引，全走磁盘 - 关外键检查：
SET FOREIGN_KEY_CHECKS=0;，避免逐条验证外键约束 - 增大日志缓冲：
SET GLOBAL innodb_log_buffer_size = 67108864;（64MB），减少日志刷盘频率 - 临时调大
innodb_log_file_size（需停库重做日志文件），能显著减少 checkpoint 频率，但操作重，非紧急不推荐
mysqldump 导出时没加 --skip-extended-insert，导入时更慢
默认 mysqldump 用批量 INSERT（INSERT INTO t VALUES (...),(...),(...);），看着省语句，但 MySQL 解析长 SQL 更耗 CPU，且事务粒度大，undo log 和 buffer pool 压力翻倍。尤其当单条 INSERT 含几百上千行时，buffer pool 很难有效缓存热页。
实操建议：
- 重导数据：用
mysqldump --skip-extended-insert重新 dump，生成多条单行 INSERT，让 buffer pool 更易命中、刷脏更平滑 - 或导入前用 sed 处理：
sed 's/),(/);\nINSERT INTO /g' backup.sql > backup_split.sql（简单粗暴，慎用于含括号的字段值） - 配合
innodb_flush_log_at_trx_commit=2（仅限导入机，非生产！），降低刷 redolog 频率
SSD 也慢？可能是 buffer pool 实例没对齐 CPU 核数
高并发导入（如多线程 mysql 连接或用 mydumper/myloader）下，innodb_buffer_pool_instances 设置不当会引发 mutex 争用，所有线程抢同一段 LRU list 锁，CPU 利用率低但导入卡顿。
实操建议：
- 设为 CPU 核心数（
nproc输出值），但不超过 64；例如 16 核机器设innodb_buffer_pool_instances = 16 - 该值必须整除
innodb_buffer_pool_size（如 8GB / 16 = 512MB/instance），否则 MySQL 启动失败并报错Buffer pool size can't be divided by buffer pool instances - 不能动态改，必须改
my.cnf并重启
buffer pool 不是越大越好，实例数不是越多越顺——真正卡点常在“多个参数咬合失配”，而不是单个值没调够。
