数据量超100GB时优先选物理备份；xtrabackup等工具直接拷贝文件，200GB库全备仅12分钟，远快于mysqldump的90分钟，因顺序读I/O更高效，但需innodb_file_per_table开启且不支持MyISAM热备。
数据量超 100GB 时，优先考虑物理备份
物理备份（如 mysqldump 以外的 xtrabackup 或 mysqlbackup）直接拷贝 InnoDB 数据文件和日志，速度远快于逐行导出 SQL。实测 200GB 库用 xtrabackup 全备耗时约 12 分钟，而 mysqldump --single-transaction 耗时近 90 分钟——差异主要来自磁盘 I/O 模式（顺序读 vs 随机查询 + 格式化输出）。
但要注意：xtrabackup 要求 MySQL 开启 innodb_file_per_table，且不支持 MyISAM 表的热备（会锁表）。若库中混有大量 MyISAM 表，物理备份反而可能因锁表导致业务中断。
- 适用场景：主从延迟敏感、RPO/RTO 要求严（如恢复窗口
- 恢复时长关键在“准备阶段”：
xtrabackup --prepare是 CPU 密集型操作，200GB 备份可能耗 20+ 分钟，不能跳过 - 备份后必须验证：
xtrabackup --test-decrypt（若启用加密）、innobackupex --apply-log后检查ibdata1文件大小是否合理
需要跨版本/跨引擎迁移时，只能选逻辑备份
物理备份本质是文件快照，MySQL 5.7 的 ibd 文件无法直接在 8.0 上启动；同样，MyISAM 表的 .MYD/.MYI 在 8.0 默认禁用，强行拷贝会报错 Unknown storage engine 'MyISAM'。
此时 mysqldump 是唯一通用方案，但它不是万能的：
-
mysqldump --no-create-info适合只同步数据，但需手动建库建表，容易漏掉COLLATE或PARTITION定义 - 大表导出易失败：
max_allowed_packet不够会中断，建议设为512M；同时加--skip-triggers --skip-routines避免存储过程权限问题 - 恢复慢的主因是单线程导入，可用
mysql -u -p db_name ，但更优解是拆成多份 + <code>parallel调度（需提前按表拆分并处理外键约束）
恢复时间要求
纯全量物理备份恢复仍要重放全部 binlog，若每天产生 20GB binlog，恢复可能卡在日志解析上。真实低 RTO 场景必须组合使用：
- 每日一次
xtrabackup --backup全备 - 每小时执行
xtrabackup --incremental，基于上次全备或增量备份做差异 - 恢复时按顺序
--apply-log全备 → 增量1 → 增量2 → … → 最后--apply-log --redo-only终止点
注意：--incremental 不依赖 binlog，但恢复到指定时间点仍需配合 mysqlbinlog 解析，且增量链断裂（如某次备份失败未察觉）会导致整条链失效。
小数据量（
装 percona-xtrabackup 依赖多（libev, qpress），配置复杂，而 mysqldump 几乎零成本。5GB 库用 mysqldump --single-transaction --routines --triggers 导出通常在 40 秒内完成，压缩后
真正容易被忽略的是字符集陷阱：
- 导出时没加
--default-character-set=utf8mb4，恢复时中文变???? -
mysqldump默认不导出CREATE DATABASE，跨环境恢复要手动CREATE DATABASE ... CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 若用
zstd压缩（比gzip快 3 倍），恢复前必须确认目标机器已安装zstd并用zstd -d dump.sql.zst | mysql
备份方案没有银弹，物理备份快但脆弱，逻辑备份慢但灵活。数据量只是起点，真正决定成败的是你能否在故障时刻准确还原出那条 binlog 位置、是否记得 xtrabackup 恢复后要 chown -R mysql:mysql、以及有没有在测试库跑过至少一次完整恢复流程。
