摘要

前段时间不小心把uat环境的库删了，苦逼的是尽然没有备份。只找到一份 frm 和 ibd 文件，没办法只能手动修复了。网上找了一些资料，感觉不太好用。索性自己搞了一套方法。

准备工作

Windows下部署一套mysql, 以及navicat。其实Linux环境也行，只是windows 下操作方便，会节省好多时间。 创建用于修复数据的临时数据库。

开始操作

（1） 找一份原来的表模型，初始化所有的表。
（2）批量生成操作的SQL，DISCARD TABLESPACE 作用是删除所有表的 ibd 文件
SELECT CONCAT('ALTER TABLE ‘, table_name, ’ DISCARD TABLESPACE;’)
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = ‘prod’;
（3）将之前的ibd 文件 拷贝到临时数据库存放数据的文件夹里，如图所示。

（4）批量生成操作的SQL，IMPORT TABLESPACE 作用是导入新的 ibd 文件，并回复表的数据。这个操作必须在DISCARD TABLESPACE之后做，不然会报异常的。如下图。

批量生成SQL：
SELECT CONCAT('ALTER TABLE ‘, table_name, ’ IMPORT TABLESPACE;’)
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = ‘prod’;
这样可以生成批量导入的ibd的SQL，然后直接执行，执行过程中时刻关注下mysql 的ERROR日志。

（5）检查所有的表是否已经恢复完了。
SELECT CONCAT('select count(*) from ', table_name)
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = ‘prod’;
批量执行生成的SQL，如果执行过程中遇到了异常，就说明那个表恢复出问题了，需要单独处理。

遇到的问题以及解决方法

如果以上每个操作都很顺利，说明你的运气不错，但是实际操作过程中会遇到很多问题。
(1) 表模型对不上了，可以参考博客：https://blog.csdn.net/zhchs2012/article/details/79013951
(2) 数据库挂了。没办法，只能重启服务，通过步骤（5）检查下哪些表还没有恢复，然后重复执行步骤（4）
(3）有些表是有索引的，发现恢复数据后 通过select count(*) from talbe查询会报异常,index被破坏了。这表示索引文件没有修复啊。没办法，这时只能删除表的索引，然后重新 从 第（2）重新执行。

（4）第一次查询表是好的，但是再次查询发现表挂了。这时只能DISCARD TABLESPACE后，重新copy ibd文件，然后IMPORT TABLESPACE。紧接着 用 select * from talbename 查询所有的记录，并通过navicat复制成insert SQL 存放到SQL文件中，用于修复数据。如果表太大的化，也可以通过 navicat 转储表结构和数据。最后重启数据库服务，并执行整理好的SQL 文件。