MySQL备份恢复失败是运维和开发中经常遇到的棘手问题。恢复过程涉及备份文件、数据库实例状态、系统权限和配置参数等多个环节，任何一处不匹配都可能导致报错或静默中断。只有建立清晰的排查路径，才能在最短时间内定位根因。
一、明确备份类型与恢复方式
排查的第一步是确认你使用的是逻辑备份还是物理备份。逻辑备份通常指用mysqldump导出的SQL文本文件，恢复时通过mysql客户端执行；物理备份则是直接复制数据目录或使用xtrabackup等工具生成的文件，恢复时需要替换或初始化数据目录。两者排查方向差异极大，混淆类型会浪费大量时间。
例如，用mysqldump备份时如果没加--databases参数，文件里可能没有CREATE DATABASE语句，直接导入就会报“未知数据库”。而物理备份若没停库或没用一致快照，恢复后极易出现表损坏。因此拿到失败任务，先问一句：备份是怎么做的？
1.1 逻辑备份恢复的典型错误
逻辑备份恢复最常见的报错包括ERROR 1046 (3D000): No database selected以及编码错误。很多人在恢复时直接执行mysql < backup.sql，却忘了先建库或选库。正确的做法是在文件开头确认是否有USE语句，或者手动指定库名。
下面是一段容易出错的恢复命令与改进写法：
# 错误示范：未指定库，且文件无建库语句 mysql < backup.sql # 正确示范：先建库再导入 mysql -e "CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4;" mysql mydb < backup.sql
1.2 物理备份恢复的注意点
物理备份恢复要重点检查数据目录属主是否为mysql用户，以及配置文件my.cnf中的datadir路径。权限不对会报Can't find file或Permission denied。另外，不同MySQL版本间直接拷贝数据目录经常不兼容，尤其是跨大版本时。
使用xtrabackup恢复后必须执行--prepare阶段，否则表空间不一致。很多人跳过这步直接启动，导致崩溃。物理恢复更偏底层，排查时要结合系统日志与MySQL错误日志一起看。
二、从错误日志提取关键信号
MySQL错误日志是排查恢复失败最核心的信息源。恢复中断时，日志里通常会记录errno、错误描述以及发生错误的线程。比如errno: 28代表磁盘空间不足，errno: 13是权限拒绝。忽略日志直接重试，往往重复踩坑。
建议恢复前临时调低log_error_verbosity以便拿到更详细输出，或在执行SQL恢复时加上--verbose。对于大文件恢复，可以后台执行并重定向输出到文件，方便事后分析。
2.1 常见errno对照
下面列出几个恢复场景中高频出现的系统错误码及其含义，帮助快速判断方向：
| errno | 含义 | 排查动作 |
|---|---|---|
| 13 | 权限拒绝 | 检查文件属主与目录权限 |
| 28 | 设备无空间 | 清理磁盘或扩容 |
| 150 | 外键约束失败 | 调整导入顺序或临时关闭外键检查 |
| 1146 | 表不存在 | 确认备份是否完整或字符集匹配 |
例如恢复时遇到1146，不一定是备份丢表，也可能是目标实例的lower_case_table_names设置与备份时不同，导致大小写匹配失败。这类问题在Linux与Windows间迁移备份时尤为突出。
2.2 利用通用查询日志辅助
如果错误日志信息有限，可短暂开启通用查询日志（general log），观察恢复执行到哪条语句中断。注意生产环境别长开，否则性能损耗明显。
在排查mysqldump恢复卡住时，还可以用SHOW PROCESSLIST看当前线程状态。若是Sending data长期不动，可能是单表过大或索引缺失引起，并非备份本身损坏。
三、版本与参数兼容性核查
MySQL不同版本对SQL语法和默认参数支持不同。用新版本客户端恢复旧版本备份，可能因sql_mode stricter而失败；反之，旧版本无法识别新版本导出的窗口函数等语法。恢复前务必比对源端与目标端版本。
另外一个隐蔽坑是character_set与collation。备份文件里若指定了utf8mb4_0900_ai_ci，而目标实例是MySQL 5.7（不支持该排序规则），恢复会直接报错。此时需手动替换排序规则或升级实例。
3.1 调整sql_mode绕过限制
临时放宽sql_mode可解决一部分语法兼容问题，但不推荐作为长期方案。示例如下：
-- 查看当前sql_mode SELECT @@sql_mode; -- 临时关闭严格模式与会话级ONLY_FULL_GROUP_BY SET SESSION sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
上面代码仅对当前会话生效，恢复完建议还原。若备份中有明显不兼容语法，还是应当修正备份文件，而非依赖降级模式掩盖问题。
3.2 存储引擎差异
备份表若使用MyISAM而目标实例禁用了该引擎，恢复会失败。反之InnoDB在innodb_file_per_table设置不同时，物理恢复路径也不一样。用SHOW ENGINES确认目标端支持情况，再决定恢复策略。
逻辑备份中可通过sed批量替换引擎声明，但物理备份则必须在配置文件层保证引擎可用。这也是为什么恢复前做环境摸底是省时间的关键。
四、权限与操作系统层检查
很多恢复失败表面是MySQL报错，根子却在系统层。比如备份文件放在/home下，而mysql用户无读取权限；或磁盘挂载了noexec导致无法写临时文件。用ls -l与df -h做基础确认，能排除大量干扰。
SELinux或AppArmor在部分发行版会限制mysqld读取非标准目录。遇到权限类errno但属主正确时，可临时设为宽容模式验证。这类问题在容器化部署中相对少，但在裸机环境常见。
4.1 文件完整性校验
备份文件传输中可能损坏。恢复前用md5sum比对源端与目标端，或用gzip -t测试压缩包。逻辑备份可头几行看是否以-- MySQL dump开头，避免拿到空文件或半截文件。
# 校验压缩备份完整性 gzip -t backup.sql.gz && echo "OK" || echo "CORRUPT" # 查看dump文件头部 head -n 5 backup.sql
如果头部正常但中途报错，多半是某条数据触发了约束或编码异常，结合第二节的日志方法定位具体行号即可。
4.2 临时目录空间
MySQL恢复大备份时会大量使用tmpdir。若tmpdir所在分区过小，会报Error writing file。通过SELECT @@tmpdir;确认路径，并保证其有足够空间，必要时临时改到大数据盘。
操作系统层的排查虽然基础，却最容易被忽视。不少团队花数小时查SQL，最后发现是/tmp满了，这类低级坑本可一分钟规避。
五、构建标准恢复核查清单
为了避免每次恢复都从头摸索，建议整理一份 checklist：备份类型确认、版本比对、错误日志抓取、权限与空间检查、参数兼容。按清单顺序执行，能将平均恢复耗时降低一半以上。
同时，定期做恢复演练比事后排查更有价值。在隔离环境用最新备份跑一遍恢复，提前暴露问题，真到故障切换时才不会手忙脚乱。备份的价值不在于备，而在于能恢复。
5.1 清单示例
- 确认备份方式：mysqldump / xtrabackup / 冷拷贝
- 目标实例版本与字符集核对
- 错误日志与系统日志并行查看
- 数据目录与临时目录空间、权限
- 恢复后执行CHECK TABLE验证
把上述步骤写成脚本或半自动工具，新人也能顺利完成恢复。技术排查的本质，是把未知问题变成可重复流程。
5.2 恢复后验证
恢复完成不等于成功。用CHECK TABLE或业务冒烟测试确认数据可读可写。逻辑备份可比对表行数，物理备份可看错误日志有无修复记录。验证环节缺失，往往在业务高峰才暴露隐患。
整体来看，MySQL备份恢复失败并不可怕，可怕的是无方法论地盲目重试。抓住类型、日志、兼容、系统四要素，绝大多数故障都能在半小时内定位。