物理备份是直接拷贝MySQL数据文件，依赖实例状态和存储引擎，需一致性保障；逻辑备份导出SQL语句，与引擎无关、可跨版本恢复；生产中常混合使用二者。
物理备份是直接拷贝 MySQL 的数据文件
物理备份本质是复制 ibdata1、ib_logfile0、表空间文件（.ibd）、mysql 系统库目录、以及 my.cnf 配置等原始文件。它依赖 MySQL 实例的运行状态和存储引擎，尤其是 InnoDB 表必须在一致性状态下（如使用 FLUSH TABLES WITH READ LOCK 或配合 mysqldump --single-transaction 无法替代）才能安全拷贝。
常见工具包括：Percona XtraBackup（主流，支持热备）、rsync（冷备需停库）、cp（仅限测试环境）。备份速度快、恢复快，但跨版本/跨平台/跨架构（如 x86 → ARM）基本不可用，且无法只恢复单张表或某几行数据。
- 必须确保 MySQL 使用的是
innodb_file_per_table=ON，否则所有表共享ibdata1，单表恢复几乎不可能 -
XtraBackup备份时会自动记录binlog位置和gtid_executed，这对搭建从库很关键 - 恢复前必须用
xtrabackup --prepare回滚未提交事务、前滚已提交事务，否则mysqld启动失败并报错InnoDB: Database page corruption on disk
逻辑备份导出的是 SQL 语句或文本格式的数据
逻辑备份不碰数据文件，而是通过客户端连接 MySQL，执行 SELECT 抽取数据，再拼成 INSERT、CREATE TABLE 等可执行 SQL。核心工具是 mysqldump 和 mydumper（多线程、更高效），MySQL 8.0+ 还可使用 mysqlpump（已弃用）或官方推荐的 mysqlshell 中的 util.dumpInstance()。
它与存储引擎无关，备份结果是纯文本，可读、可编辑、可跨版本恢复（只要语法兼容），也支持按库、按表、甚至按条件（--where）导出。
生产级WordPress REST API集成，用于管理文章、页面、媒体、WooCommerce产品、Elementor内容、SEO元数据、ACF及JetEngine字段
-
mysqldump --single-transaction对 InnoDB 有效，利用 MVCC 快照保证一致性；但对 MyISAM 仍需全局锁，生产环境慎用 -
mysqldump --skip-triggers --skip-routines可避免导出触发器和存储过程——如果目标实例没权限或不需要，否则恢复时可能报ERROR 1419 (HY000) - 大表导出易超时或 OOM，建议加
--quick --extended-insert=FALSE控制内存占用；导入时用set unique_checks=0; set foreign_key_checks=0;加速
选物理还是逻辑？看恢复粒度和迁移需求
物理备份适合整实例灾难恢复、主从快速搭建、或对 RTO（恢复时间目标）要求极严的场景（如秒级恢复）。逻辑备份更适合开发测试数据同步、跨版本升级前验证、审计合规导出、或只需恢复某几张表/某个库的情况。
- 线上主库每日全量 + binlog 增量：推荐
XtraBackup全备 +mysqlbinlog --read-from-remote-server拉取 binlog - 向测试环境推送指定业务库：用
mysqldump -B db_order db_user > backup.sql更灵活 - 误删了
user表里某条记录，且没开 binlog：只能靠最近一次逻辑备份 + 手动INSERT回填，物理备份此时无能为力
混合策略才是生产常态
真实运维中几乎不会只用一种。典型做法是：每周一次 XtraBackup 物理全备（保留 4 周），每天凌晨用 mysqldump 做逻辑增量（只 dump 变更频繁的小库），同时开启 binlog 并定期归档。恢复时先还原物理备份到某时间点，再用 mysqlbinlog 重放至故障前一秒，最后用逻辑备份补漏（比如跳过某条坏数据）。
最容易被忽略的是权限校验：物理备份恢复后，mysql.user 表里的账号密码哈希值直接生效，但若原库用的是 caching_sha2_password 插件而目标 MySQL 版本太低，客户端连不上；逻辑备份默认导出 CREATE USER 语句，却可能因目标实例未加载对应认证插件而失败。
