MySQL恢复前须先区分备份类型：SQL备份用mysql客户端导入，物理备份需先apply-log再拷贝并改权限；导入SQL时需确保实例运行、权限充足，避免CREATE DATABASE缺失或source大文件。
确认备份文件类型再操作
MySQL 恢复前必须分清备份是 mysqldump 生成的 SQL 文本，还是 xtrabackup 或 mysqlbackup 做的物理备份。两者恢复路径完全不同：SQL 备份用 mysql 客户端导入；物理备份需先 innobackupex --apply-log 再拷贝到 datadir 并改权限。混用会直接导致服务启动失败或数据不一致。
用 mysql 命令导入 SQL 备份时的常见坑
导入前确保目标 MySQL 实例已运行，且用户有对应库的 CREATE 和 INSERT 权限。执行命令时注意：
- 不要在 SQL 文件里带
CREATE DATABASE语句却忽略-e "CREATE DATABASE IF NOT EXISTS db_name"，否则库不存在会报错ERROR 1049 (42000): Unknown database - 避免用
source backup.sql在 MySQL 客户端内执行大文件——容易因超时或内存溢出中断，应改用 shell 层：mysql -u root -p db_name - 若备份含
SET FOREIGN_KEY_CHECKS=0，但目标表结构未提前创建，导入会卡在约束校验上；建议先mysql -e "CREATE DATABASE db_name"，再导入
跨版本恢复要注意 sql_mode 和字符集
从 MySQL 5.7 恢复到 8.0 时，sql_mode 默认值变化（如移除了 NO_AUTO_CREATE_USER），可能导致 INSERT 报错；同样，备份中若含 utf8mb4_0900_as_cs 排序规则，而目标实例未启用 collation_server=utf8mb4_0900_as_cs，建表会失败。
实操建议：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 导入前在目标实例执行：
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'; - 检查备份文件头是否有
SET NAMES utf8mb4，并确认目标my.cnf中character-set-server=utf8mb4已生效 - 对 5.7 → 8.0 迁移，优先用
mysqldump --skip-set-charset --default-character-set=utf8mb4重备一次
物理备份恢复后必须重做权限和日志路径
用 xtrabackup 恢复到新服务器后，datadir 下的文件属主仍是原服务器的 mysql:mysql，但新机器可能用不同 UID/GID；同时 innodb_log_file_size 若与原配置不一致，MySQL 启动会拒绝加载。
关键步骤：
- 执行
chown -R mysql:mysql /var/lib/mysql（路径以实际datadir为准） - 删掉旧日志文件：
rm -f /var/lib/mysql/ib_logfile*，让 MySQL 启动时按my.cnf里的innodb_log_file_size重建 - 检查
server-id是否唯一——若用于主从，必须修改，否则复制线程起不来
物理恢复完成后，务必用 mysqlcheck -u root -p --all-databases --check 快速验证表结构完整性，别只看服务是否启动成功。
