MySQL 备份应优先用 Percona XtraBackup 物理备份替代 mysqldump 逻辑备份，支持增量与内置压缩；逻辑备份时须 pigz 压缩、按表分块、过滤无用数据；同时从源头清理历史数据、归档冷数据，并校验备份完整性与可恢复性。
MySQL 备份文件太大，核心是减少体积、加快传输、节省存储，同时不牺牲可恢复性。关键不在“删什么”，而在“怎么备”和“怎么压”。
优先用物理备份替代逻辑备份
mysqldump 生成的 SQL 文本文件体积大、恢复慢，尤其对大表或含大量 BLOB 字段的库。生产环境建议切换为 Percona XtraBackup：
- 直接拷贝 InnoDB 数据文件，不解析 SQL，备份速度快、体积更接近原始数据占用
- 支持增量备份（–incremental），只备份变更页，大幅降低单次备份量
- 内置压缩选项：加 –compress（用 QuickLZ）或配合—stream=xbstream –compress 再管道进 pigz，实现边备份边多线程压缩
逻辑备份时强制压缩与分块
若必须用 mysqldump（如需跨版本迁移、审计 SQL 内容），别裸导出：
- 用 mysqldump –single-transaction | pigz > backup.sql.gz 代替 gzip——pigz 默认启用所有 CPU 核，压缩速度提升 3–5 倍
- 按表拆分：写脚本遍历SHOW TABLES，对每个大表单独 dump+ 压缩，便于后续并行恢复或选择性还原
- 跳过无业务价值的数据：用 –ignore-table=db.log_table 排除日志表；用 –where=”created_at > ‘2024-01-01’ 导出近期数据
从源头控制备份体积
备份大，往往因为数据本身冗余或结构不合理：
- 清理历史数据：在备份前执行 DELETE FROM audit_log WHERE created，再OPTIMIZE TABLE 释放。ibd 空间（注意锁表影响）
- 检查并关闭低效功能：确认 innodb_file_per_table=ON，避免所有表挤在 ibdata1 里无法收缩；禁用general_log 和slow_query_log（除非调试需要）
- 归档冷数据：把旧订单、日志等迁出主库，存为压缩 CSV 或转到对象存储，主库只留热数据，备份自然变小
备份后自动精简与验证
备份完成不是终点，而是校验起点：
- 用 pigz -t backup.sql.gz 快速校验压缩包完整性，避免备份损坏却未察觉
- 保留最近 3 次全备 + 7 天内增量，其余自动清理；用 find /backup -name “*.gz” -mtime +7 -delete 定时清理
- 每周抽样恢复一个库到测试环境，用 pt-table-checksum 比对主备一致性，确保压缩没丢数据
