mysql整库恢复需匹配备份方式：mysqldump逻辑备份须先创建同名数据库并确保字符集一致（如utf8mb4），再用mysql客户端导入sql文件；物理备份则不可混用。
MySQL 整个数据库的恢复，本质上就是把之前备份的 SQL 文件（或物理文件）重新导入到 MySQL 实例中。能否成功恢复，取决于你当初用什么方式备份——mysqldump 生成的逻辑备份和 xtrabackup 做的物理备份，恢复流程完全不同，混用会直接失败。
用 mysqldump 备份后，如何恢复整个数据库
这是最常见的情况：你执行过类似 mysqldump -u root -p mydb > mydb.sql 的命令。恢复时不是“启动某个恢复模式”，而是用 mysql 客户端执行 SQL 导入。
- 目标数据库（如
mydb）必须已存在；如果不存在，先运行CREATE database mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 确保字符集一致，否则可能乱码；
mysqldump默认不带--default-character-set时，常按服务器默认字符集导出，导入前建议检查SHOW varIABLES LIKE 'character_set_database'; - 执行导入：
mysql -u root -p mydb ；注意不要加 <code>-e或试图用source在交互式客户端里执行大文件，容易中断或超时 - 如果备份文件含
CREATE DATABASE和USE语句，且你想恢复到同名库，可跳过手动建库，但要确认原库是否允许被覆盖（例如有重要表未备份）
用 xtrabackup 做物理备份后，如何恢复整个数据库
物理恢复不走 SQL 解析，速度更快，但要求 MySQL 版本、数据目录结构、甚至 innodb_page_size 都严格匹配。它不能像 mysql 命令那样“一键导入”。
- 必须停掉 MySQL 服务：
systemctl stop mysql（或对应服务名） - 清空原
datadir（如/var/lib/mysql），不能只删库目录，必须清空整个数据目录，否则启动失败 - 用
xtrabackup --copy-back --target-dir=/path/to/backup/把备份文件拷回datadir；注意权限：恢复后的文件属主必须是mysql用户，需跟chown -R mysql:mysql /var/lib/mysql - 重启 MySQL 后，首次启动可能卡在 InnoDB 恢复阶段（apply log），看错误日志里有没有
InnoDB: Starting crash recovery，这是正常现象
恢复失败的几个典型错误信号
看到这些提示，基本能定位是哪类问题：
-
Error 1049 (42000): Unknown database 'mydb'→ 数据库不存在，先CREATE DATABASE -
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'→ 表已存在且有数据，而备份含INSERT；要么清空表，要么加--ignore-table跳过，或改用mysqldump --replace备份 -
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'→ MySQL 没在运行，或 socket 路径不对；检查mysql --socket=...或配置文件里的socket项 - 物理恢复后 MySQL 启动失败，日志里反复出现
InnoDB: Unable to lock ./ibdata1→ 文件权限没改对，或者还有残留的mysqld进程锁着文件
真正麻烦的不是操作步骤，而是备份那一刻的上下文：用了什么参数、有没有开 GTID、binlog 是否启用、是否跨版本恢复。这些细节不会写在备份文件名里，但会决定恢复能不能跑通。