mysqldump是MySQL全量备份最常用且稳妥的选择，导出可读SQL文本，支持多粒度备份，但需加–single-transaction等参数保障一致性；mysqlpump更快但兼容性受限；xtrabackup适合大库物理备份；全量备份必须搭配binlog才能实现时间点恢复。
mysqldump 全量备份最常用也最稳妥
生产环境里，mysqldump 是 MySQL 全量备份的默认选择，它导出的是可读的 SQL 文本，兼容性好、恢复直观、支持单库/多库/表级粒度。但要注意：它默认不锁表，可能造成一致性问题。
实操建议：
- 加
--single-transaction（仅对 InnoDB 有效）：在事务快照中导出，避免锁表，保证逻辑一致性 - 加
--routines --triggers --events：否则存储过程、触发器、事件不会被包含 - 加
--set-gtid-purged=OFF（若备份用于 GTID 环境且不打算做主从同步）：避免恢复时报 GTID 冲突 - 用
--databases显式指定库名，比--all-databases更可控；后者会把information_schema等系统库也拉进来，多数场景不需要 - 示例命令：
mysqldump -u root -p --single-transaction --routines --triggers --events --databases app_db > backup_20240515.sql
mysqlpump 比 mysqldump 更快但兼容性受限
mysqlpump 是 MySQL 5.7+ 引入的并行导出工具，支持多线程、按表并行、更细粒度的过滤。但它不支持 MySQL 5.6 及更早版本，且某些旧客户端或脚本可能识别不了它的输出格式。
关键差异点：
- 默认开启并行（
--default-parallelism=2），可通过--parallel-schemas控制并发粒度 - 不支持
--single-transaction，而是用--skip-lock-tables+ 隐式快照，对 MyISAM 表仍可能不一致 - 不导出
mysql系统库中的权限数据（如user表），需额外用mysqldump --no-create-info --no-data mysql.user单独备份 - 示例：
mysqlpump -u root -p --single-transaction --include-databases=app_db > backup_pump.sql
物理备份（xtrabackup）适合大库但门槛更高
当数据库超过 50 GB 或要求秒级 RPO，mysqldump 就显得太慢——它走 SQL 层，IO 和 CPU 开销大，且备份期间写入压力仍存在。这时应考虑 Percona XtraBackup 这类物理备份工具。
注意几个硬性前提：
- 只支持 InnoDB/XtraDB，MyISAM 表需额外处理（会自动加全局读锁）
- 必须与 MySQL 版本严格匹配（例如 MySQL 8.0.33 要用 xtrabackup 8.0.33）
- 备份过程不阻塞写入，但恢复不是直接替换文件：要先
--prepare（回滚未提交事务、前滚已提交事务），再拷回数据目录 - 不能跨版本恢复（如 MySQL 5.7 备份不能直接恢复到 8.0）
- 示例备份：
xtrabackup --backup --target-dir=/backup/full_20240515/ --user=root --password=xxx
忽略 binlog 和时间点恢复就等于没做真正备份
全量备份只是基础。如果只依赖每天一次 mysqldump，那最后一次备份之后的所有变更都丢了。必须搭配 binlog 才能实现任意时间点恢复（PITR）。
关键操作项：
- 确认
log_bin已开启（SHOW VARIABLES LIKE 'log_bin';返回 ON） - 记录每次全备对应的
binlog filename和position（mysqldump加--master-data=2会自动在 SQL 文件头写入） - 定期轮转并保留 binlog（通过
expire_logs_days或手动PURGE BINARY LOGS） - 恢复时顺序执行：全量 SQL →
mysqlbinlog --start-position=xxx binlog.000001 | mysql -u root -p
最容易被跳过的其实是 binlog 的归档路径和权限管理——备份机上没同步 binlog，或者磁盘满导致日志被自动清理，全量备份就变成“单点故障”。