导入大sql文件前需关闭外键和唯一性检查，否则校验导致速度骤降至几行/秒；应先执行set foreign_key_checks=0;和set unique_checks=0;再导入。
恢复前必须关掉这两个检查
不关 FOREIGN_KEY_CHECKS 和 UNIQUE_CHECKS，几十 GB 的 SQL 文件导入时会边插边校验外键和唯一索引，速度直接掉到几行/秒。这不是数据量问题，是 MySQL 在反复做无意义的约束验证。
实操建议：
- 导入前连上数据库，先执行：
SET FOREIGN_KEY_CHECKS=0;和SET UNIQUE_CHECKS=0; - 如果用
mysql命令直接导入（如mysql -u root -p db ），这两条语句得写在 SQL 文件最开头；否则需手动进 <a style="color:#f60; text-decoration:underline;" title="mysql" href="https://m.php.cn/zt/15713.html" target="_blank">mysql</a> 执行 - 导入完成后记得设回：
SET FOREIGN_KEY_CHECKS=1;、SET UNIQUE_CHECKS=1;，否则后续写入可能出错
别硬扛 mysqldump，换 mydumper + myloader
mysqldump 是单线程文本导出，对百 GB 级数据已严重过时。它生成的 SQL 文件大、导入慢、无法并发、不支持自动分片——不是你配置不对，是工具本身能力边界到了。
真正提速的关键是换工具链：
- 导出用
mydumper：支持多线程、自动按表拆分、内置压缩（--compress）、可指定 chunk 大小（--chunk-filesize=100M） - 导入用
myloader：默认多线程（--threads=8起步），能并行导入多个表，且跳过已存在表（--overwrite-tables）避免中断 - 命令示例：
myloader -u root -p password -B db_name -d /backup/ --threads=8
恢复时临时调低 InnoDB 日志和双写开销
默认 innodb_log_file_size（常见 48MB）太小，大量 INSERT 会频繁触发 checkpoint，I/O 卡死在日志刷盘上；而 innodb_doublewrite=ON 在恢复这种一次性场景里纯属冗余。
操作要点：
- 恢复前动态关闭双写：
SET GLOBAL innodb_doublewrite = OFF;（完事后务必设回ON） - 确认
innodb_flush_log_at_trx_commit=2（不强制每 COMMIT 刷盘，只写 OS cache） - 若版本支持动态调整
innodb_log_file_size，建议设为 1–2G；否则需停库改配置+重建日志文件
导入完立刻补索引和统计信息
关约束导入或用 myloader 导入后，所有二级索引都是空的。MySQL 不会批量建索引，而是等第一条查询触发延迟创建——结果就是首查极慢、执行计划全错、后续查询性能雪崩。
必须手动补：
- 对每个大表执行
ALTER TABLE table_name ENGINE=InnoDB;（触发索引重建） - 或者更精准地：先
ANALYZE TABLE table_name;更新统计信息，再OPTIMIZE TABLE table_name;（适用于有大量 DELETE/UPDATE 后的碎片整理） - 别依赖“导入完成就完事”，没建好索引的库，等于没恢复成功
