mysqldump 备份会显著升高 CPU 和 I/O：读取数据、序列化 SQL、加锁判断耗 CPU，磁盘随机读（MyISAM）或缓冲池压力（InnoDB）加剧 I/O；业务写入频繁时脏页上涨拖慢查询。
mysqldump 备份时 CPU 和 I/O 会明显升高
直接跑 mysqldump 时，MySQL 会读取表数据、生成 SQL 文本，这个过程既占 CPU（序列化、压缩、加锁判断），也大量触发磁盘随机读（尤其 MyISAM）或缓冲池压力（InnoDB）。如果备份期间业务写入频繁，innodb_buffer_pool_pages_dirty 可能快速上涨，间接拖慢查询响应。
实操建议：
- 避开业务高峰执行，用
--single-transaction（仅 InnoDB）减少锁表时间，但无法消除读负载 - 加
--skip-triggers --skip-routines减少元数据读取开销 - 用
--compress降低网络传输压力，但会多占 CPU；若本地备份，建议关掉 - 对大库考虑分表导出，配合
--where或按主键范围切片，避免单次长事务
恢复（source / mysql -e）比备份更吃资源
导入 SQL 文件本质是重放所有 INSERT 语句，每条都走完整解析、优化、写 redo、刷脏页流程。默认 autocommit=1 时，每条 INSERT 都是一次事务提交，I/O 放大严重；若文件含 CREATE TABLE + INSERT，还会触发大量元数据锁和 buffer pool 冷启动抖动。
实操建议：
- 导入前执行
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; SET AUTOCOMMIT=0;，最后再COMMIT;提交 - 用
mysql --max-allowed-packet=512M避免大行被截断，否则恢复中断且难定位 - InnoDB 表优先用
mysqlpump（MySQL 5.7+）或mydumper（支持多线程导出/导入），比单线程mysqldump快 3–5 倍 - 确认目标实例的
innodb_log_file_size足够大，否则大批量插入易触发 checkpoint 频繁刷盘
物理备份（xtrabackup）对运行中实例影响更小但有前提
xtrabackup 的核心优势是拷贝数据文件 + 增量 redo，不经过 SQL 层，因此不触发解析、优化器、锁等待等开销。但它仍需读取 ibdata1、ib_logfile* 和所有 .ibd，对磁盘带宽和缓存压力真实存在——尤其是 LVM 快照方式，可能引发短暂 IO stall。
