如何加快 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; SET unique_checks=0; SET foreign_key_checks=0;）；②调大 InnoDB 缓冲与日志（buffer pool、log file）；③换并行工具（mydumper/myloader）或裸文件备份。实际收益取决于表结构、存储、事务与工具配置，应在独立恢复实例验证。
方法一：会话级优化（改 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：可合并部分事务，但 dump 中 DDL、锁表语句和显式提交可能造成隐式/显式提交，不保证全库一个事务unique_checks=0：允许存储引擎优化部分唯一性检查，不能当作无条件忽略重复键的开关，需保证输入数据有效foreign_key_checks=0：暂时关闭外键检查；重新打开不会自动扫描验证此前导入的数据
方法二：恢复期间调大配置
my.cnf 临时调整（恢复后可还原）：
[mysqld]
innodb_buffer_pool_size = 4G # 示例值，按可用内存与其他进程开销计算
innodb_redo_log_capacity = 2G # MySQL 8.0.30+；旧版使用相应 redo 配置
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，性能需按权限、表结构与输入测试 |
| Percona XtraBackup | 物理备份，需执行兼容版本的备份准备、恢复与权限处理，不能只拷文件起库 |
方法四：硬件与传输
- dump 先 gunzip 再喂给 mysql 时用管道省落盘：
zcat dump.sql.gz | mysql mydb - 恢复到 NVMe 盘、内存富余的机器上明显更快
- 同机恢复用 socket 连接比 TCP 略省
常见问题（FAQ）
Q：恢复中途失败要从头再来吗？
A：只会回滚仍未提交且支持事务的部分；DDL 和此前已提交数据可能保留。应检查失败位置及恢复目标状态，重跑前避免重复写入，不保证全库整体回滚。
Q：恢复后查询很慢？
A：统计信息过时，跑 ANALYZE TABLE；索引在恢复期间被延迟创建的版本也要确认索引完整。
Q：为什么 myloader 比 mysql 客户端快那么多？
A：多线程并行导表+每表分批事务，充分利用多核与 I/O 并发；单线程 mysql 客户端是串行逐条。
