MySQL备份恢复里头，咋只弄回一个数据库，不想全盘恢复怎么办

基于MySQL官方文档中关于mysql客户端工具和mysqlpump/mysqldump工具的说明，以及常见的数据库管理实践经验。）

当你的MySQL服务器上有很多个数据库,但只是不小心把其中一个数据库，比如叫“shop”的库，给弄坏了，比如误删了重要的数据表，这个时候你肯定不想把整个服务器的数据都倒退回昨天的备份状态，因为那样会把其他好好的数据库也给覆盖了，你的目标很明确：只把那个出问题的“shop”数据库恢复成备份时的样子，其他数据库保持现状不动。

要实现这个目标,最关键的一点在于你之前是怎么做备份的，如果你的备份是把整个MySQL服务器所有的数据库都打包成一个巨大的文件，那么想只恢复其中一个就会比较麻烦，先从备份策略说起。

理想的备份方式：每个库单独备份

最省事的办法,就是在平时备份的时候，就养成好习惯，针对每个重要的数据库进行单独的备份，使用MySQL自带的备份工具mysqldump就可以轻松做到，你只想备份“shop”数据库，备份命令大概是这样的：

mysqldump -u root -p shop > shop_backup.sql

这个命令的作用是,连接到MySQL，然后把“shop”这个数据库的结构（比如表是怎么创建的）和数据（表里每一行记录）都导出来，保存到一个叫做shop_backup.sql的文本文件里，这个文件里只包含“shop”数据库的东西，与其他数据库无关。

当“shop”数据库出问题需要恢复时，操作就非常简单直接了：

1. 确保安全：如果可能，先确认一下问题，是不是真的需要恢复，有时候可能只是某张表的问题，恢复单张表更精确（这个后面会提到）。
2. 连接MySQL：打开你的命令行或者终端。
3. 执行恢复命令：

   mysql -u root -p shop < shop_backup.sql

   这个命令的意思是,使用mysql这个客户端工具，登录到MySQL，然后告诉它：我现在要操作的是“shop”这个数据库，请你把shop_backup.sql这个文件里的所有命令（包括创建表、插入数据等）都执行一遍。

这样,文件里的内容就会在“shop”数据库中重新建立起来，覆盖掉当前已经损坏的数据，而服务器上的其他数据库，blog”、“forum”等，完全不会受到这个操作的影响，它们该干嘛干嘛。

如果备份是整个服务器的，怎么办？

但很多时候,特别是使用一些自动化备份脚本或面板工具时，它可能会图省事，直接备份整个实例的所有数据库，命令可能像这样：

mysqldump -u root -p --all-databases > full_backup.sql

这个full_backup.sql文件非常大，里面包含了所有数据库的信息，这个时候，你想从中只恢复“shop”数据库，就不能直接用上面的简单方法了，你需要先从这个大文件中把属于“shop”数据库的那部分内容“抠”出来。

这个时候,有几种思路：

1. 手动提取（适合小备份或对SQL熟悉的人）：用文本编辑器打开这个巨大的SQL文件（如果太大可能打不开），或者用grep、sed等命令行工具，你需要找到以CREATE DATABASE IF NOT EXISTS \shop`和USE `shop`开头，一直到下一个CREATE DATABASE ...语句之前的所有内容，把这些内容复制出来，保存成一个新的shop_only.sql`文件，再用恢复单个库的方法去恢复这个新文件，这个过程比较繁琐，而且如果对SQL文件结构不熟悉，很容易出错。

2. 恢复到一个临时MySQL实例（更安全可靠）：这是更推荐的做法，你可以找一台测试服务器，或者就在本机再安装一个临时的MySQL服务（端口不同即可），先把整个完整备份full_backup.sql恢复到你这个临时MySQL实例里，这样，临时实例就拥有了备份时刻所有数据库的完整状态，你再从这个“干净”的临时实例中，使用mysqldump工具，单独把“shop”数据库备份出来，生成一个我们上面说的shop_backup.sql文件，再用这个新提取的单个库备份文件，去恢复生产环境里那个损坏的“shop”数据库，这个方法虽然步骤多了一步，但安全系数高，不容易出错，尤其适合处理重要的生产数据。

3. 使用工具辅助：有一些第三方工具或脚本可以帮助你从一个完整的备份文件中拆分出单个数据库，可以搜索“split mysql dump”之类的关键词来找找看，但使用前务必在测试环境验证其可靠性。

更精细的操作：只恢复单张表

问题可能更局部,你只是误删了“shop”数据库里的“users”表，那么恢复整个“shop”库虽然能解决问题，但可能会丢失从备份之后到故障发生之前，这个库里其他表新增加的数据（比如新下的订单），如果能只恢复那张坏掉的“users”表，就更完美了。

这同样取决于你的备份习惯,如果你在备份“shop”库时，使用了类似下面的命令，为每个表生成独立的备份文件：

mysqldump -u root -p shop table1 table2 table3 ... > shop_tables_separate.sql

或者更高级点,用脚本为每个表都生成一个单独的.sql文件，那么恢复单张表就和恢复单个库一样简单，只需要找到对应表的备份文件，然后执行mysql -u root -p shop < table_users_backup.sql即可。

如果备份文件还是整个库的,你也可以尝试用上面提到的“手动提取”方法，从库的备份文件中找出创建和填充“users”表的那部分SQL语句，但这对SQL的阅读能力要求更高。

重要提醒

无论采用哪种恢复方式,有几点必须牢记：

• 先备份再操作：在恢复任何数据之前，只要条件允许，务必先对当前出问题的数据库甚至整个服务器再做一次备份！这样万一恢复操作不但没成功反而让情况更糟，你至少还能退回到恢复前的状态。
• 在测试环境演练：恢复流程，尤其是复杂的提取操作，一定要先在非生产环境的测试服务器上反复练习，确认无误后再在生产环境操作。
• 检查备份文件：定期检查你的备份文件是否真的有效，可以尝试在测试机恢复一下看看，无效的备份比没有备份更可怕。

只想恢复MySQL中的一个数据库,最根本的解决之道是做好“分库备份”，如果不得已面对全库备份文件，则可以通过提取或搭建临时实例的方式“过滤”出所需库的数据，操作的关键是谨慎和提前测试。