MySQL 8.0 还原后无法启动，主因是 XtraBackup 与 MySQL 小版本不一致、残留 ib\_logfile*、innodb\_redo\_log\_encrypt 配置错误或误用 --apply-log-only；须严格匹配版本、清空重做日志、显式配置加密参数并正确执行 prepare。
还原后 MySQL 8.0 服务无法启动，八成不是备份坏了，而是 mysqld 启动时直接拒绝加载——它在重做日志（ib_logfile*）或配置兼容性上卡死了。
检查 XtraBackup 与 MySQL 主版本号是否完全一致
MySQL 8.0.33 的备份，用 XtraBackup 8.0.34 恢复，可能失败；用 XtraBackup 8.0.26 去恢复 8.0.33 的实例，大概率报 InnoDB: Unsupported redo log format 或静默退出。
- 必须执行
mysql --version和xtrabackup --version，确认输出的第一段数字（如8.0.33）完全相同 - Percona Server 用户额外注意后缀：比如源库是
percona-server-80-8.0.33-25.1.el8，XtraBackup 就得用percona-xtrabackup-80-8.0.33-25.1.el8 - 别信“都是 8.0 就行”——小版本间 redo 日志格式可能有微调，官方 release note 里会写清楚
确认目标目录下没有残留或错误的 ib_logfile*
MySQL 启动前会校验 ib_logfile0 和 ib_logfile1 的大小、checksum、加密状态。这些文件不能从备份里带过来，也不能留着旧实例生成的。
- XtraBackup 全量备份默认不打包
ib_logfile*；如果你手动复制过、或--copy-back前没清空目标目录，就极可能混入不兼容日志文件 - 启动前，务必删除目标
datadir下所有ib_logfile*（包括ib_logfile0、ib_logfile1，甚至ib_redo*） - 查源库实际值：
SELECT @@innodb_log_file_size;，并在目标my.cnf中显式写死该值，不要依赖默认
留意 innodb_redo_log_encrypt 这个隐藏雷区
MySQL 8.0.30+ 新增了重做日志加密开关。如果源库没开（OFF），但目标 my.cnf 里误配了 innodb_redo_log_encrypt=ON，mysqld 会尝试解密一个未加密的日志，直接崩溃。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 还原前，检查源库是否启用：
SELECT @@innodb_redo_log_encrypt; - 若为
OFF，目标my.cnf中必须明确写innodb_redo_log_encrypt=OFF，哪怕你没配过这行，也建议显式补上 - 这个参数不会出现在老版本配置模板里，很容易被忽略；错误日志中可能只显示
InnoDB: Error: failed to decrypt redo log这类模糊提示
prepare 阶段是否误用了 --apply-log-only
这个参数常被当成“加速恢复”的捷径，但它会让备份处于不可启动状态——数据页已应用，但事务未回滚、重做日志未重放，表空间元数据也不完整。
- 仅测试/演练可用：
xtrabackup --prepare --apply-log-only --target-dir=/path/to/backup - 生产环境必须再跑一次不带
--apply-log-only的--prepare，否则启动时报Tablespace is not found - 含增量备份时，所有增量都要加
--apply-log-only，只有最后一次全量--prepare不加
最常被跳过的动作，不是删 ib_logfile*，而是在 my.cnf 里补全 innodb_redo_log_encrypt 显式配置——哪怕源库关着，目标也得关，且必须写出来。
