关闭 InnoDB 的 doublewrite 和 redo 日志能显著提速吗？
可以，但仅限于非生产环境的单次恢复。MySQL 恢复慢的主因之一是 InnoDB 在写入过程中持续刷盘：doublewrite buffer 保证页完整性，redo log 保证崩溃可恢复——这两者在批量导入时属于冗余开销。
实操建议：
恢复前执行SET GLOBAL innodb_doublewrite = OFF（需 SUPER 权限） 临时禁用 redo：先停库，修改配置文件中
innodb_log_file_size = 0并设
innodb_flush_log_at_trx_commit = 2，再启动；或更安全的做法是使用
mysqld --innodb-log-file-size=0 --innodb-flush-log-at-trx-commit=2启动专用恢复实例 恢复完成后必须重新启用 doublewrite 和正常 redo 配置，并执行一次干净 shutdown，否则后续无法启动
注意：
innodb_doublewrite = OFF在 MySQL 8.0.20+ 中已不可动态设置，必须改配置重启；且该操作会使数据面临页断裂风险，严禁用于线上库。
用 mysql
命令行导入 SQL 文件时怎么避免逐行解析瓶颈？
默认
mysql -u root -p 是客户端逐行发送、服务端逐条解析执行，网络和解析开销大，尤其含大量 <code>INSERT语句时。
更快的方式是让服务端直接读取文件：
登录后执行source /path/to/dump.sql，比命令行重定向快 20%~40%，因跳过客户端解析和网络往返 更优的是用
mysqlimport或
LOAD DATA INFILE替代
INSERT——前提是 dump 文件是 tab 分隔的纯数据（如
mysqldump --tab输出），速度可提升 5–10 倍 若必须用 SQL 文件，确保它包含
SET autocommit = 0、
SET unique_checks = 0、
SET foreign_key_checks = 0，否则每条 INSERT 都触发唯一索引和外键校验
mysqldump
备份时就该考虑恢复效率？
是的，恢复时间很大程度上由备份方式决定。一个 10GB 的
mysqldump文件，如果没做优化，恢复可能要 2 小时；加几项参数后可压到 20 分钟内。
关键备份参数组合：
--single-transaction保证一致性，但对大表仍会锁 MDL，可配合
--skip-lock-tables（需确认无 DDL 并发）
--extended-insert（默认开启）大幅减少 SQL 行数，降低解析压力
--compress不影响恢复速度，但减小传输体积；真正有用的是
--net-buffer-length=1M和
--max-allowed-packet=512M，避免客户端分包重传 对 MyISAM 表，用
--lock-tables=false+
--flush-logs可避免全局锁；InnoDB 则优先用
--single-transaction
另外，备份时拆分大表（如按月分区导出）能让恢复支持并行导入，但要求应用层能接受部分表延迟上线。
恢复时并行导入多个 SQL 文件为什么反而更慢？
因为默认 MySQL 单线程处理每个连接的语句流，多终端同时执行
mysql -e "source a.sql"、
source b.sql等，不仅不会加速，还可能引发锁争用、buffer pool 污染、I/O 随机化等问题。
真正有效的并行策略只有两种：
用mydumper+
myloader工具链：它把表按 chunk 拆成多个文件，
myloader -t 8可真正并发导入，且自动处理建表、索引重建顺序 手动分表并行：把
mysqldump拆成 per-table 文件（
mysqldump db table1 > t1.sql），再用不同连接分别导入，但必须关掉
foreign_key_checks，并在所有表导入完成后再建外键
别忽略磁盘 I/O 类型——机械盘上并发太多会把随机写变成“假并行”，SSD 才能发挥多线程优势；而 buffer pool 大小若小于总数据量，频繁换页也会抵消并发收益。
