如何加快 MySQL 从 dump 文件恢复的速度？
加速 mysqldump 恢复：关闭 unique_checks/foreign_key_checks/autocommit、加大 innodb_buffer_pool_size 与 innodb_log_file_size、用 --tab 或 mydumper 并行、关闭 binlog。恢复完记得还原配置。
核心思路：大 dump 恢复慢在"逐行 INSERT + 索引维护 + 事务开销"。加速三板斧：①会话级关掉校验与自动提交（SET autocommit=0; unique_checks=0; foreign_key_checks=0;）；②调大 InnoDB 缓冲与日志（buffer pool、log file）；③换并行工具（mydumper/myloader）或裸文件备份。几十 G 的库，这些手段能把恢复时间压到原来的几分之一。
方法一：会话级优化（改 dump 文件头部）
mysqldump 导出时加 --opt（默认开）已含部分优化；恢复前在 SQL 头部手动补：
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
-- ... 原有内容 ...
COMMIT;
SET autocommit=1;
SET unique_checks=1;
SET foreign_key_checks=1;
autocommit=0：全部插入合并成少量大事务，减少 redo 刷盘次数unique_checks=0：跳过一次索引唯一性检查foreign_key_checks=0：跳过外键校验
方法二：恢复期间调大配置
my.cnf 临时调整（恢复后可还原）：
[mysqld]
innodb_buffer_pool_size = 物理内存的 60-70%
innodb_log_file_size = 2G # 大日志减少 checkpoint
innodb_flush_log_at_trx_commit = 2 # 恢复期可接受（崩溃丢1秒）
sync_binlog = 0
skip-log-bin # 恢复期不写 binlog
innodb_flush_log_at_trx_commit=2 与关 binlog 只适合全新恢复的实例，生产在役库别这么调。
方法三：换更快的工具
| 工具 | 特点 |
|---|---|
| mydumper/myloader | 逻辑备份，多线程并行导出/导入，大库首选 |
mysqldump --tab |
导成 TSV+SQL，LOAD DATA INFILE 比 INSERT 快一个量级 |
| Percona XtraBackup | 物理备份，恢复=拷文件+起库，最快但整库粒度 |
方法四：硬件与传输
- dump 先 gunzip 再喂给 mysql 时用管道省落盘：
zcat dump.sql.gz | mysql mydb - 恢复到 NVMe 盘、内存富余的机器上明显更快
- 同机恢复用 socket 连接比 TCP 略省
观测云对照
恢复过程也要盯。 长时间恢复期间，DataKit 采集的 MySQL 指标（写入速率、redo、连接）能确认恢复是否健康推进；恢复完成后慢查询与表统计信息（analyze table）也该跟上。
常见问题（FAQ）
Q：恢复中途失败要从头再来吗？
A：autocommit=0 大事务模式下中断会整体回滚，得重来；可以按表拆 dump 分批恢复，失败只重跑当前表。
Q：恢复后查询很慢？
A：统计信息过时，跑 ANALYZE TABLE；索引在恢复期间被延迟创建的版本也要确认索引完整。
Q：为什么 myloader 比 mysql 客户端快那么多？
A：多线程并行导表+每表分批事务，充分利用多核与 I/O 并发；单线程 mysql 客户端是串行逐条。
