物理备份恢复快但跨版本/架构直接失败，因其依赖二进制文件一致性，需严格匹配innodb_log_file_size、OS架构及MySQL版本，且必须执行xtrabackup --prepare；逻辑备份可跨平台但恢复慢、易因截断或字符集问题失效。
物理备份恢复快，但跨版本/跨架构直接失败
物理备份本质是拷二进制页（.ibd、ibdata1、ib_logfile*），跳过 SQL 解析层，所以恢复时只要文件一致、权限正确、目录干净，mysqld 启动就能用。但这也意味着它对环境极其敏感：
-
xtrabackup备份后必须执行xtrabackup --prepare，否则ibdata1和日志不一致，启动报InnoDB: Operating system error number 2或Table 'mysql.user' doesn't exist - 目标机的 MySQL 版本必须兼容（如 8.0.33 备份不能恢复到 8.0.23），OS 架构也得一致（
x86_64备份无法在aarch64上启动） -
innodb_log_file_size参数必须和原实例完全相同，否则--prepare阶段就中断
逻辑备份可读可改，但恢复慢且易截断
逻辑备份生成的是纯文本 SQL 文件（mysqldump -u root -p mydb > backup.sql），内容包含 CREATE TABLE、INSERT 等语句。好处是能跨版本、跨平台，甚至手动删掉某张表再导入；坏处是恢复过程等于重放全部 DDL/DML：
- 默认单线程导入，大库恢复卡在唯一索引校验或外键约束上
- 没加
--single-transaction时可能锁表，备份期间写入被阻塞 - 文件看似“备份成功”，实则因磁盘满、字符集不匹配（如
utf8mb4列遇到latin1客户端）导致 SQL 截断或乱码——仅靠mysqldump进程退出码为 0 无法判断
小库（20GB）必须物理备份
这不是经验值，而是由 I/O 模式决定的：
- 逻辑备份走 SQL 层：备份时要读取每行数据、拼 SQL 字符串、写磁盘；恢复时再解析、校验、插入。CPU 和磁盘随机 IO 压力双高
- 物理备份走文件系统层：
xtrabackup直接read()数据文件，write()到目标路径，基本是顺序 IO，对数据库负载影响小 - 20GB 以上库用
mysqldump备份，常出现超时、连接中断、临时表空间爆满；而xtrabackup即使备份 200GB 库，也能控制在分钟级
备份后不验证可恢复性，等于没备
90% 的线上事故不是备份没做，而是备份文件不可用却没人发现。最简验证方式只有两个：
- 逻辑备份：用
head -n 100 backup.sql | mysql -u test -ptest testdb快速检查前几条语句是否语法合法 - 物理备份：在测试机上跑完整流程——
rm -rf /var/lib/mysql/*→ 拷贝备份 →xtrabackup --prepare→chown -R mysql:mysql /var/lib/mysql→mysqld --skip-grant-tables看能否启动
真正容易被忽略的，是备份时没校验源文件完整性（比如 md5sum），以及恢复验证只停留在“服务起来”，没查 SELECT COUNT(*) FROM mysql.user 确认系统表是否加载成功。
