mysqldump恢复单线程压满cpu的根本原因是语句级串行执行、索引重建开销大、约束校验未关闭及缓冲池过小；有效方案是关闭校验与binlog、调大max-allowed-packet并确保buffer_pool足够。
逻辑备份恢复（mysqldump + mysql 导入）本身不锁表，但 CPU 飙升到 100% 是典型资源过载现象，根本原因不是“备份慢”，而是恢复过程触发了大量高开销操作——尤其是没有预判的索引重建、无缓冲写入和单线程串行执行。
mysqldump 恢复时为什么单线程压满一个 CPU 核？
mysql 客户端默认以单线程顺序执行 SQL，哪怕你 dump 出来的是 100 个 INSERT 语句，它也一条接一条 parse → optimize → execute。没有并行，也没有批处理优化，所有计算压力全落在一个线程上。
- 每条 INSERT 都要走完整 SQL 生命周期：语法解析、权限检查、查询重写、执行计划生成（即使简单语句也会走一遍）
- 如果表有多个二级索引，每插入一行就要更新所有索引 B+ 树节点，CPU 花在键值比较、页分裂、内存拷贝上的时间远超磁盘写入
- 恢复时若未关闭唯一性检查（
SET UNIQUE_CHECKS=0）、外键校验（SET FOREIGN_KEY_CHECKS=0），每行还要额外做约束验证
为什么加了 --skip-extended-insert 还是卡住？
很多人以为把多值 INSERT 拆成单行 INSERT（即用 --skip-extended-insert）能“更可控”，结果反而更慢——这会让语句数量暴涨几十倍，网络往返、客户端解析、服务端语句分发开销翻倍，mysql 进程自身 CPU 占用直接冲顶。
- 原始 dump 文件中
INSERT INTO t VALUES (1),(2),(3);是 1 条语句 → 1 次 parse + 1 次执行 - 加了
--skip-extended-insert后变成 3 条独立语句 → 3 次 parse + 3 次执行 + 更多次网络 round-trip - 尤其在远程恢复时，RTT 放大效应明显，
mysql进程大部分时间在等 socket read，但 top 看仍是它占 CPU（因为等待也计入用户态时间）
innodb_buffer_pool_size 太小会放大 CPU 压力
InnoDB 缓冲池不够大时，恢复过程中频繁触发“页未命中 → 从磁盘读页 → 解析日志 → 写脏页 → 刷盘”循环，CPU 不是花在计算上，而是被大量上下文切换、锁竞争、LRU 链表遍历拖垮。
- 例如 16GB 物理内存却只配了
innodb_buffer_pool_size = 2G，而你要恢复一张 8GB 的表——几乎每插入几万行就会触发一次刷脏页，同时还要维护插入缓冲（Insert Buffer）合并，线程反复在log_write_up_to、buf_flush_batch等函数里打转 - 监控可观察
SHOW ENGINE INNODB STATUS中的FILE I/O和LOG部分，若pending normal aio reads长期 > 0，或log writes数值飙升，说明 I/O 成瓶颈，CPU 在空转等
真正有效的降 CPU 恢复方案
别指望调参数“微调”，得换执行模型。关键动作就三个：
- 导入前执行：
SET unique_checks=0; SET foreign_key_checks=0; SET sql_log_bin=0;（关掉校验和 binlog 写入） - 用
mysql --max-allowed-packet=512M -u root db_name ，避免客户端因 packet 拆包重传 - 大表单独恢复：先
CREATE TABLE，再用LOAD DATA INFILE替代 INSERT（快 5–10 倍，且可并行）；索引留到最后用ALTER TABLE ADD INDEX批量建
最容易被忽略的是最后一点：用 mysqldump --no-create-info --skip-triggers --skip-routines 导出纯数据，再手动控制建表、加索引、导入的节奏。恢复不是“扔一个文件进去就完事”，而是分阶段释放压力的过程。
