恢复前必须确认三个检查点：一是备份为完整备份且已执行--prepare；二是目标MySQL版本不低于备份版本；三是待恢复库不含MyISAM表。
恢复前必须确认的三个检查点
用 xtrabackup 恢复单个数据库，不是把备份文件解压完事——它本质是基于 InnoDB 的物理恢复，依赖一致性状态和正确的目录结构。跳过校验直接恢复，90% 会卡在 innodb_redo_log_capacity 不匹配或 ibdata1 版本冲突上。
- 确认备份是否为
--backup完整备份（非--incremental），且已执行过xtrabackup --prepare - 检查目标 MySQL 实例版本是否 ≥ 备份时的版本（比如用 8.0.33 备份不能恢复到 8.0.23）
- 确认待恢复库不含 MyISAM 表——
xtrabackup不保证 MyISAM 表一致性，这类表得单独用mysqldump补救
只恢复指定数据库的实操路径
xtrabackup 原生不支持“只恢复某个库”，它恢复的是整个实例数据目录。但你可以通过过滤 + 替换方式达成效果：先恢复到临时路径，再挑出目标库文件，最后安全替换线上对应目录。
- 用
xtrabackup --copy-back --target-dir=/path/to/backup/ --datadir=/tmp/mysql-restore/恢复到空临时目录 - 进入
/tmp/mysql-restore/，只保留你要的数据库名对应的子目录（如myapp_db/）和必要系统文件：ibdata1、ib_logfile*、mysql/、performance_schema/、sys/ - 停掉 MySQL，将目标库目录（如
/var/lib/mysql/myapp_db/）重命名为myapp_db.bak，再把临时目录里的myapp_db/移过去 - 注意权限：确保
mysql:mysql所属，且ibdata1等文件没被误删或覆盖——否则启动报错InnoDB: Operating system error number 2 in a file operation
恢复后必做的三件事
物理恢复完成不代表数据可用。InnoDB 的元数据缓存、字典状态、甚至 binlog 位点都可能断层，不验证就上线等于埋雷。
- 启动 MySQL 后立刻执行
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'myapp_db';，确认表数量与备份前一致 - 挑关键表运行
CHECK TABLE myapp_db.users;，避免因 prepare 不彻底导致页损坏 - 如果开启了 GTID，检查
SELECT @@gtid_executed;是否包含备份时的 GTID 集合；否则主从同步可能跳过部分事务
比恢复更难的是“怎么不伤其他库”
最常被忽略的一点：MySQL 的 ibdata1 是共享表空间，所有库共用。你替换了某个库的 .ibd 文件，但没同步更新 ibdata1 里的数据字典，MySQL 启动时会拒绝加载该表，报错 Tablespace is missing for table 'myapp_db/orders'。
解决办法只有一个：恢复时必须带完整的 ibdata1 和 ib_logfile*，哪怕只想要一个库——它们不是可选配件，而是 InnoDB 的心跳。
