干这行久了，谁没在深夜还原过几个数据库呢。特别是那种几百个G的备份文件，往服务器上一丢，敲下回车，屏幕滚过几行日志，然后啪一声，红字报错。那一刻的心情，比看恐怖片还刺激。MySQL还原报错这事儿，太常见了，常见到很多老手都懒得看日志直接凭经验猜。但猜来猜去，坑还是那个坑，今天咱们就把这些坑一个个扒开，看看底下到底埋着什么。
第一个坑，最经典的，就是“Unknown database”或者“Can't create database”这类权限和库不存在的报错。很多人拿到一个.sql文件，习惯性直接执行 ，结果系统根本不认识你要往哪个库塞数据。原因很简单，备份文件里如果没有语句，或者你当前登录的用户对目标库没有建表权限，那MySQL直接甩脸子。解决办法也直接：先手动建好同名数据库，再指定库导入，比如。如果还是报权限错，那就去查用户授权，，然后。别嫌麻烦，这一步省了，后面全白干。
第二个高频报错是“ERROR 1064 (42000): You have an error in your SQL syntax”。这玩意儿看着吓人，其实多半不是SQL语句本身写错了，而是字符集和排序规则不匹配。比如备份文件是UTF-8，但你的数据库连接默认是latin1，那中文字符全变成乱码，然后MySQL在解析某些特殊字符时直接报语法错。解决思路就一句话：统一字符集。导入前先执行，再用参数指定连接字符集。如果备份文件本身是GBK的，那就改成。另外，检查一下表结构里有没有用明确指定，如果建表语句里没写，那就要在导入前先把库的默认字符集改掉，。
第三个常见问题，是“ERROR 1146 (42S02): Table 'xxx' doesn't exist”。这报错特别迷惑人，因为明明备份文件里有这张表。但仔细一想，大概率是备份文件里的表名带了库名前缀，比如，而你导入时当前库是另一个名字。或者更隐蔽的，是备份文件里包含了视图、触发器、存储过程，这些对象在创建时引用了绝对路径的库名。解决办法：打开.sql文件，用文本编辑器全局搜索和，看看有没有硬编码的库名，有就批量替换成你现在的库名。再不行，就在导入前用明确切换当前库，别让MySQL猜你想往哪放。
第四个坑，是“ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails”。外键约束报错，这个在还原大库时尤其常见。因为备份文件是按逻辑顺序导出的，可能先插入了子表数据，然后才插入父表数据，这时候外键检查直接拦住。解决办法有两招：第一招，导入前先临时关闭外键检查，，导入完再恢复成1。第二招，如果备份文件太大没法手动加这句，那就用命令带参数。这招百试不爽，但记住导入完成后一定要重新开启，不然后面应用层写数据全乱套。
第五个报错，是“ERROR 1114 (HY000): The table 'xxx' is full”。这名字听着像磁盘满了，其实分两种情况。一种是磁盘真的满了，看一眼就知道。另一种是InnoDB的表空间文件达到上限，特别是老版本MySQL的设置成了固定大小，比如1GB，数据一超就报这个错。解决办法：如果磁盘满了，清理日志或者扩容。如果是表空间限制，修改my.cnf里的，改成，然后重启MySQL。但注意，改这个文件要小心，别把现有数据搞坏了，最好先备份。
第六个，也是很多人忽略的，是“ERROR 2006 (HY000): MySQL server has gone away”。这个报错特别烦人，因为不是语法问题，是连接被服务端掐断了。常见原因有：备份文件太大，超过了的限制；或者导入过程耗时太长，超过了和。解决办法：临时调大这两个值，比如（1GB），，。如果还不放心，直接在mysql命令行加参数。另外，用命令而不是重定向导入，有时候能避开一些连接中断的坑，因为是客户端逐条解析的，不会一次性把整个文件塞给服务端。
一个坑，是“ERROR 1045 (28000): Access denied for user”。这报错最直接，权限不够。但有时候你明明用root导入了，还是报这个。那可能是备份文件里包含了子句，比如视图或存储过程指定了，而当前库里没这个用户。解决办法：要么创建对应的用户，要么在导入前用sed把文件里的部分替换掉。比如[^@]*。这招处理老项目迁移特别管用，不然你永远不知道下一个报错会指向哪个不存在的用户。
说到底，MySQL还原报错，大部分都是环境不一致造成的。要么是字符集没对齐，要么是权限和对象引用出了问题，要么是连接参数太小。真遇到报错，别慌，先看错误码，再查日志，用看看内部状态。很多时候，问题不在SQL本身，而在你执行SQL的方式和环境。多准备几个常用参数，多留几份不同字符集的备份，比什么都强。下次再遇到还原报错，先喝口水，按着这几个思路排查一遍，多半能解决。要是还解决不了，那就看看是不是备份文件本身就已经损坏了，这时候别硬刚，找之前的全量备份加binlog增量恢复，才是正路。
