MySQL备份分物理、逻辑、二进制日志增量、快照四类：物理备份速度快但兼容性差；逻辑备份可读可编辑但慢且大；binlog实现增量需配合全量；快照适合超大实例但依赖存储。
MySQL 的备份方式主要围绕怎么备和备什么两个维度展开，实际选型需结合数据库规模、业务连续性要求、恢复时间目标（RTO）与恢复点目标（RPO）来定。下面分四类常见方式说明，覆盖操作逻辑、适用场景和关键注意事项。
物理备份：直接拷贝数据库文件
物理备份是复制 MySQL 的底层数据文件（如 .ibd、.frm、ib_logfile* 等），本质是操作系统级的文件拷贝。
- 冷备份：必须停掉 MySQL 服务，确保文件一致性；适合小库或可接受停机的维护窗口
- 热备份：数据库运行中完成，依赖 InnoDB 的崩溃恢复机制，常用工具如
Percona XtraBackup；支持大库秒级备份，不锁表 - 温备份：MyISAM 表常用，加读锁后拷贝，期间允许查询但禁止写入；已逐步被 InnoDB + 热备替代
优点是速度快、恢复快；缺点是跨版本/跨平台兼容性差，不能只恢复单个表（除非文件粒度可控），且不包含配置项和二进制日志。
逻辑备份：导出 SQL 或文本格式数据
逻辑备份通过 MySQL 客户端工具将结构（CREATE）和数据（INSERT）转为可读脚本或文本，最典型的是 mysqldump。
- 支持全库、单库、单表甚至按条件导出（
--where） - 备份时数据库可在线，但大表导出会加重主库负载，建议在从库执行
- 生成的 SQL 文件可人工审查、编辑、跨版本迁移，也便于做数据脱敏或结构改造
缺点是备份和恢复都比物理备份慢，文件体积通常更大，且不包含用户权限、存储过程等非表对象（除非显式加 --routines --triggers --events）。
基于二进制日志的增量备份
MySQL 本身不提供“增量备份”命令，但可通过开启并管理 binlog 实现增量能力——它记录所有数据变更（DML 和 DDL）。
- 配合一次全量备份（物理或逻辑），后续只需定期保存新增的 binlog 文件
- 恢复时先还原全量，再按时间点或事务位置重放 binlog，实现精确到秒的 RPO
- 需注意 binlog 格式（推荐
ROW）、过期策略（expire_logs_days）及落盘安全（sync_binlog=1）
这是构建高可用备份链路的核心一环，单独使用无意义，必须与全量备份协同。
快照备份（文件系统/存储层）
不是 MySQL 原生功能，而是借助底层存储能力（如 LVM 快照、ZFS 快照、云盘快照）对整个数据目录做瞬间一致性拷贝。
- 几乎零耗时，不干扰数据库运行，特别适合超大实例（TB 级以上）
- 依赖存储系统支持，且快照本身只是指针，仍需配合异步拷贝到远程或归档存储
- 恢复时需确保 MySQL 配置、日志路径、UUID 等与原环境一致，否则可能启动失败
常作为物理备份的加速补充，多见于云环境或企业级 SAN/NAS 架构中。
不复杂但容易忽略：无论哪种方式，都要定期验证备份可用性（比如抽样导入测试库），并把备份文件存放在独立物理位置或异地，避免单点故障连带丢失。
