mysqldump备份时cpu和i/o突增需优化：加–single-transaction、–skip-query-cache、–net-buffer-Length=16384，禁用触发器/存储过程/事件，本地写入高速磁盘，用–disable-keys等提升效率，超大表分批导出；xtrabackup因物理备份更高效。
mysqldump 备份时 CPU 和 I/O 突增怎么办
直接用默认 mysqldump 备份大库（比如 >50GB），常导致 MySQL 查询响应变慢、从库延迟飙升，甚至触发监控告警。根本原因是 mysqldump 默认单线程全表扫描 + 无缓冲写入，会争抢磁盘 I/O 和 Buffer Pool。
- 加
--single-transaction（InnoDB 必选）避免锁表，但不能降低 I/O 压力 - 强制禁用查询缓存：
--skip-query-cache，防止 dump 过程中缓存失效抖动 - 调低客户端缓冲区：
--net-buffer-length=16384，减少内存占用和网络堆积 - 用
--skip-triggers --skip-routines --skip-events拆分备份对象，后续单独导出更可控
如何让 mysqldump 写入更快而不卡主库
瓶颈往往不在 MySQL 服务端，而在 dump 输出的写入速度——尤其是直连远程服务器并重定向到本地磁盘时，网络+磁盘双重延迟明显。
- 优先在数据库服务器本地执行 dump，并用
--result-file=/path/to/backup.sql直接写入高速磁盘（避开 NFS 或慢盘） - 禁用自动提交和外键检查：
--disable-keys --extended-insert --skip-autocommit，大幅提升导入时的恢复速度，也间接减轻 dump 阶段的事务开销 - 对超大表单独处理：用
--where="1 limit 1000000"分批导出，或改用select ... INTO OUTFILE配合LOAD DATA INFILE - 避免压缩在 MySQL 进程内做：
mysqldump | gzip会让 mysqldump 进程等待 gzip 缓冲，改用stdbuf -oL mysqldump | gzip降低阻塞
Percona XtraBackup 比 mysqldump 快在哪
mysqldump 是逻辑备份，要解析 SQL；xtrabackup 是物理备份，直接拷贝 InnoDB 数据文件（ibd）和 redo log，不经过 SQL 层，因此吞吐量高一个数量级。
- 热备期间只短暂加全局读锁（几毫秒），不影响业务 DML
- 支持流式备份：
xtrabackup --stream=xbstream可边拷贝边压缩传输，减少中间磁盘压力 - 增量备份依赖 LSN，比
mysqldump --where手动模拟更可靠，但要求开启innodb_file_per_table - 注意：XtraBackup 5.7+ 版本不再支持 MySQL 5.6，且 8.0 备份需匹配对应版本，否则
apply-log会报Unsupported redo log format
备份时影响从库延迟的关键配置
如果备份在从库执行，mysqldump 的全表扫描会大量触发 SELECT，加剧 relay log 应用延迟，尤其当 slave_parallel_workers > 0 时，容易因元数据锁（MDL）阻塞 SQL Thread。
- 务必在从库停掉 SQL Thread 后再备份：
STOP SLAVE SQL_THREAD，备份完再START SLAVE SQL_THREAD - 设置
innodb_old_blocks_time=1000，避免 dump 扫描污染 Buffer Pool 热数据区 - 用
--set-gtid-purged=OFF避免 GTID 相关元数据锁竞争（MySQL 5.7+） - 不要在备份期间执行
FLUSH TABLES WITH READ LOCK—— 它会阻塞所有更新，包括复制线程
备份快不等于安全。真正难的是验证备份可恢复性、校验一致性（比如 pt-table-checksum 对比主从）、以及控制备份窗口与 purge binlog 的节奏。这些环节一旦漏掉，再快的备份也只是假象。