恢复前必须确认目标数据库已存在，执行 mysql -u root -p database_name 命令时需确保 database_name 已通过 create database 创建，否则会报错“unknown database”。
恢复前必须确认目标数据库已存在
执行 mysql -u root -p database_name 时，如果 <code>database_name 不存在，会直接报错 ERROR 1049 (42000): Unknown database 'xxx'。mysqldump 默认不自动创建库（除非用了 --databases 或 --all-databases 参数），所以得手动建库。
建库命令很简单：
mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS testdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"- 字符集建议显式指定，尤其当备份文件里有中文或 emoji，避免恢复后乱码
- 如果备份时用了
--routines或--events，建库后还需确保用户有CREATE ROUTINE、EVENT权限，否则存储过程/事件会跳过
恢复命令本身没陷阱，但路径和权限常出问题
常见错误不是语法错，而是 shell 层面的权限或路径问题：
- 备份文件路径写错，比如
/backup/test.sql实际在/home/backup/下，导致No such file or directory - 当前 shell 用户对备份文件无读取权限（尤其用
sudo或不同用户生成的备份），需chmod 644 backup.sql或用对应用户执行 - MySQL 客户端连接失败：检查
-h是否漏了（默认 localhost），远程恢复要加-h 10.0.1.5；密码输错或用户无目标库写权限也会卡在登录环节 - 大文件恢复超时：默认 MySQL 连接超时是 30 秒，恢复前可临时设大点：
mysql -u root -p --connect-timeout=3600 testdb
含特殊对象（视图/函数/事件）的备份恢复失败怎么办
如果备份用了 --routines、--events、--triggers，但恢复后发现函数没创建、事件没启用，大概率是权限或 SQL 模式问题：
- 检查当前用户是否被授予
CREATE ROUTINE、EXECUTE、EVENT权限，缺一不可 - MySQL 8.0+ 默认开启
sql_mode=STRICT_TRANS_TABLES，而旧版备份可能含不兼容语法（如空字符串插入时间字段），可在恢复前临时关闭：mysql -u root -p -e "SET GLOBAL sql_mode='';"（仅临时生效） - 视图依赖的表若未按顺序创建（比如先建视图再建基表），会报
ERROR 1356 (HY000)；mysqldump 默认已处理依赖顺序，但如果手动删改过备份文件，顺序可能被破坏
恢复后数据不对？先看这几件事
恢复完成不代表数据正确，尤其跨版本或压缩传输后：
- 检查备份文件末尾是否有完整
COMMIT;或UNLOCK TABLES;—— 若备份中途中断，文件末尾截断，恢复会漏数据 - 对比行数：
mysql -u root -p -Nse "SELECT COUNT(*) FROM testdb.users;"和备份前记录是否一致 - 确认字符集：用
head -n 20 backup.sql | grep "CHARACTER SET"看导出时用的字符集，再查目标库：SHOW CREATE DATABASE testdb;，两者不一致会导致中文变 ? - 如果备份用了
--single-transaction，恢复的是某个一致性快照，但业务写入没停，恢复后看到的是“过去某刻”的数据，不是最新状态
真正麻烦的不是命令敲错，而是恢复后没人校验——哪怕只挑三张核心表 count 一下，也能避开 80% 的线上事故。
