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，或者磁盘满导致日志被自动清理，全量备份就变成“单点故障”。
