应避开业务高峰时段执行备份，优先使用物理备份+增量策略，挂载独立磁盘，合理控制并发与I/O优先级，并利用专用从库备份以减少主库压力。
MySQL备份本身会占用磁盘I/O、CPU和内存资源，尤其在业务高峰期执行全量备份，容易导致查询变慢、连接超时甚至主从延迟。关键不是“要不要备份”，而是“怎么备才不拖慢线上服务”。
避开业务高峰时段执行备份
备份操作本质是大量读取数据文件或执行SELECT，会争抢系统资源。建议将mysqldump、xtrabackup等任务安排在凌晨低峰期（如02:00–04:00），并结合业务监控确认实际低负载窗口。
- 用cron配合系统负载检查，例如[ $(cat /proc/loadavg | awk '{print $1}')
- 对核心库可进一步限制备份起始时间，避免与报表生成、日终结算等任务重叠
优先使用物理备份 + 增量策略
mysqldump属于逻辑备份，需解析SQL再写入，速度慢、锁表风险高；而Percona XtraBackup等物理备份工具支持热备、压缩、流式传输，对运行中的MySQL影响更小。
- 全量备份每周1次，增量备份每天1次（基于LSN），恢复时只需最新全量+后续增量
- 启用--parallel=4 --compress --stream=xbstream参数提升效率并减少临时空间占用
- 备份目标挂载到独立磁盘（非数据库数据盘或系统盘），避免I/O干扰
控制备份并发与资源占用
多库并行备份看似快，实则可能压垮I/O队列；单次备份线程过多也会挤占Buffer Pool。应根据服务器配置合理限流。
- 对SSD服务器，--parallel=2~4较稳妥；HDD环境建议--parallel=1
- mysqldump加--single-transaction --skip-lock-tables，避免长事务阻塞
- 通过ionice -c2 -n7降低备份进程的I/O优先级，让业务请求优先响应
善用复制从库做备份源
直接在主库备份等于给生产加压。若已部署主从架构，可在专用从库上执行备份，既不影响主库性能，又能验证从库可用性。
- 备份前先STOP SLAVE SQL_THREAD，确保备份点一致；完成后立即START SLAVE
- 该从库不对外提供读服务，仅用于备份和应急切换，避免其他负载干扰
- 定期校验从库延迟（Seconds_Behind_Master ≈ 0），防止备份出的是“过期数据”
