必须执行--prepare才能恢复，因为备份时InnoDB数据文件处于非一致性状态：存在未刷盘的已提交事务（靠redo log）和未提交事务，直接恢复会报错；--prepare通过前滚redo log和回滚未提交事务，使数据回到备份完成时刻的一致性状态。
为什么必须执行 --prepare 才能恢复？
备份时 MySQL 正在运行，InnoDB 数据文件处于“非一致性状态”：可能有已提交但还没刷到磁盘的事务（靠 redo log 记录），也可能有正在执行却未提交的事务。直接把备份文件拷回去启动 MySQL 会报错，比如 InnoDB: Database page corruption 或 Tablespace is missing。--prepare 就是模拟 MySQL 崩溃重启时做的那件事——前滚已提交事务、回滚未提交事务，让数据回到备份完成那一刻的事务一致点。
xtrabackup --prepare 默认行为就是回滚未提交事务
不需要额外加参数，默认执行 --prepare 就会做两件事：应用 redo log（前滚）和回滚未提交事务（undo）。这是安全恢复的必要步骤，也是生产环境唯一推荐的方式。
- 命令格式：
xtrabackup --prepare --target-dir=/backup/xtrabackup_full - 执行后，
xtrabackup_checkpoints文件中backup_type会变成full-prepared，state变为prepared - 如果中途失败（比如磁盘空间不足），不能跳过重试，必须清空目标目录重新 prepare
什么情况下要加 --apply-log-only？
只在处理增量备份链时用。全备 + 多次增量恢复时，前 N-1 次增量必须用 --apply-log-only，否则它会提前回滚事务，导致后续增量无法合并。
- 全备准备：
xtrabackup --prepare --target-dir=/backup/full - 第一次增量（必须加）：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc1 - 第二次增量（同样加）：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc2 - 最后一步才不加：
xtrabackup --prepare --target-dir=/backup/full（此时才真正回滚未提交事务）
容易忽略的关键点
prepare 过程不依赖 MySQL 实例是否运行，但它强依赖备份时的 xtrabackup 版本与目标 MySQL 版本兼容性。比如用 xtrabackup 8.0 备份 MySQL 5.7 的库，prepare 时若混用 2.4 版本二进制，大概率卡在 Applying a partial rollback 或报 Unknown redo log format。务必确认 xtrabackup --version 输出的版本号与你的 MySQL 主版本匹配（5.7 → xtrabackup 2.4，8.0+ → xtrabackup 80）。
