MySQL恢复报错应先看错误码：ERROR 1045为账号密码或权限问题；ERROR 1146需确认表是否存在及数据库名是否正确；ERROR 2002/2003表明服务未启动或连接配置错误；ERROR 1064多因SQL语法不兼容。
看终端报错代码，别只读文字描述
终端里那串 ERROR 1045、ERROR 1146 或 ERROR 2002 比“Access denied”或“Can’t connect”有用得多。MySQL 错误码是定位问题的硬指标，不是修饰语。
-
ERROR 1045：基本就是账号密码错，或用户没被授权访问目标库，不是网络或服务问题 -
ERROR 1146：“Table doesn’t exist”——但别急着建表，先确认backup.sql里是否真有这张表的CREATE TABLE语句，也可能是数据库名写错或没提前CREATE DATABASE -
ERROR 2002/ERROR 2003：MySQL 进程压根没跑起来，或者 socket 路径/端口配置和客户端不一致，跟备份文件无关 -
ERROR 1064：SQL 语法错误，常见于高版本导出的语句（如带JSON_TABLE或窗口函数）往低版本导入，或mysqldump时漏了--compatible
查 error.log 最开头几行，不是末尾
MySQL 启动或恢复失败时，真正致命的线索全在错误日志最前面——通常是第 1～5 行。翻到末尾找“Aborting”或“Shutdown”反而会错过判决书。
- 紧盯以
InnoDB:开头的ERROR行，比如InnoDB: Database page corruption on disk，这是物理损坏的铁证 -
The log sequence number in ibdata1 does not match：说明 redo log 和数据文件 LSN 不一致，大概率是强制 kill 后直接拷贝了数据目录，删掉ib_logfile0和ib_logfile1就能救活 -
Failed to initialize transaction sub-system：undo log 异常，通常重建日志即可，不是数据损坏 - 看到
Unable to lock ./ibdata1？先ps aux | grep mysql看有没有残留进程，再检查文件权限，别一上来就设innodb_force_recovery
验证备份文件本身是否可用
很多“恢复失败”其实发生在第一步——你根本没拿到一个能用的备份。别跳过校验，尤其当备份是远程传过来或跨平台复制的。
- 用
head -n 30 backup.sql看开头是否有CREATE DATABASE或USE语句，空文件或截断文件一眼就能识破 - 执行
md5sum backup.sql对比备份时记录的哈希值；若无原始值，至少用grep "INSERT" backup.sql | wc -l确认有实质数据 - 在测试库中试导入前 100 行：
head -n 100 backup.sql | mysql -u root -p testdb，快速暴露语法或权限问题 - 如果备份来自
mysqldump --single-transaction，但恢复时报ERROR 1205（死锁），很可能是目标实例开了innodb_lock_wait_timeout过短，或并发恢复脚本干扰
权限与上下文环境最容易被忽略
同一个 mysql -u root -p dbname 命令，在不同机器上失败原因可能完全不同。问题常藏在看不见的上下文里。
- 目标库不存在？命令里写的
dbname必须已存在，否则加-e "CREATE DATABASE IF NOT EXISTS dbname"预处理 - 字符集不匹配：原库是
utf8mb4_0900_as_cs，目标 MySQL 8.0 实例默认是utf8mb4_0900_ai_ci，导入时可能卡在某个COLLATE定义上，用sed -i 's/utf8mb4_0900_as_cs/utf8mb4_0900_ai_ci/g' backup.sql临时绕过 - GTID 模式冲突：备份含
SET @@GLOBAL.GTID_PURGED，但目标实例没开 GTID，必须加--set-gtid-purged=OFF参数导入 - Linux 下表名大小写敏感：备份里是
CREATE TABLE User，但目标my.cnf里lower_case_table_names=1，会导致后续INSERT INTO User找不到表——这类问题只在跨配置迁移时爆发
