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。
实操建议：
必须关闭innodb_fast_shutdown=1（非 2），否则备份后首次启动会做 crash recovery，看起来像“恢复慢” 备份时加
--parallel=4 --compress --compress-threads=2可平衡 CPU 与 I/O，但别设过高，否则挤占业务线程 不要在从库上用
--slave-info同时又开启 GTID，会导致
CHANGE MASTER TO语句生成错误的
MASTER_AUTO_POSITION=0恢复后务必检查
SHOW SLAVE STATUS\G中的
Seconds_Behind_Master是否归零，xtrabackup 不保证 relay log 一致性
备份策略本身决定性能影响持续时间
影响大小不只看工具，更取决于你“什么时候备、备什么、保留几份”。例如每天全量备份 100GB 库，即使用了 xtrabackup，凌晨 2 点开始的 2 小时拷贝仍可能让从库复制延迟跳到 30 分钟以上——因为主库的写入压力会传导到从库的 apply 线程。
实操建议：
全量 + 增量组合：每天一次 xtrabackup 全备，每小时mysqlbinlog --read-from-remote-server拉取 binlog，恢复时先全备再追增量，缩短窗口 关键业务库单独备份，避免和其他大表混在一个
mysqldump进程里互相阻塞 监控
Threads_running和
Innodb_row_lock_time_avg在备份窗口内的突增，这是最直接的性能扰动信号 不要依赖“备份完成即安全”，物理备份后必须做
innobackupex --apply-log，否则恢复时会卡在 redo 解析阶段
备份不是“设好 cron 就完事”的操作，真正影响性能的往往是恢复路径设计不合理、参数没调、或把备份当成黑盒对待。最容易被忽略的是：备份后的校验环节——没有
md5sum校验或
mysqlcheck --check验证，等于埋了个定时故障。
