前言
MySQL的数据库其相关文件都会存放在安装目录下data文件夹下的同命文件夹中，不同的存储引擎创建的表其文件也不一样，下面来认识下这些数据库文件。
db.opt
用来记录该库的默认字符集编码和字符集排序规则用的。也就是说如果你创建数据库指定默认字符集和排序规则，那么后续创建的表如果没有指定字符集和排序规则，那么该新建的表将采用db.opt文件中指定的属性。
.frm
与表相关的元数据信息都存放在.frm文件中,主要是表结构的定义信息,不论什么存储引擎,每一个表都会有一个以表名命名的.frm文件。
.MYD和.MYI
.MYD：MY Data，是MyISAM存储引擎专用的用于存放MyISAM表的数据；
.MYI：MY Index，也是专属于MyISAM存储引擎的主要存放MyISAM表的索引相关信息。
.ibd和.ibdata
两者都是专属于InnoDB存储引擎的数据库文件。
当采用共享表空间时所有InnoDB表的数据均存放在.ibdata中，所以当表越来越多时，这个文件会变得很大；
相对应的.ibd就是采用独享表空间时InnoDB表的数据文件。
修改为独享表空间的方法是在my.ini配置文件中添加/修改此条：
Innodb_file_per_table=1
注意：笔者所用的MySQL-5.7是默认独享表空间的，不用特意在配置文件中添加。
当然，就算开启了独享表空间，.ibdata文件也会越来越大，因为这个文件里还存储了：
- 变更缓冲区
- 双写缓冲区
- 撤销日志
这些东西究竟是啥玩意儿？我也不知道233
如果是MyISAM存储引擎，直接拷贝.frm、.MYD、.MYI到新的库文件夹下就行了，简直方便快捷简单易用。但现在MySQL在不配置的情况下默认的存储引擎是InnoDB，说明它还是有优越性在的。具体两者的差异有空另起一篇或者网上查查资料吧，三言两语说不清楚，这里就不展开了。
当然，能点进这篇博客的肯定是想看InnoDB表的数据恢复，尤其是丢失了.ibdata文件的情况下。
一、恢复表结构
首要的一件事情就是恢复表结构，如果很幸运地保留了当时的表结构，此步可跳过。
1.1 随意创建一张同名表
CREATE TABLE weibo_tweets(a int)ENGINE=InnoDB;
- 1
1.2 关闭mysql服务
net stop mysql
1.3 复制备份的.frm覆盖新建的表.frm
1.4 开启mysql服务
net start mysql
1.5 在mysql安装目录data文件夹下用文本编辑器打开.err文件
这是mysql的错误日志，找到诸如
2018-01-09T08:19:46.170814Z 3 [Warning] InnoDB: Table data_rec/weibo_tweets contains 1 user defined columns in InnoDB, but 6 columns in MySQL. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS
的记录,发现原表拥有6个字段。
1.6 删除当前表，新建一张拥有6个字段的同名表
mysql> DROP TABLE weibo_tweets;
Query OK, 0 rows affected (0.26 sec)
mysql>CREATE TABLE weibo_tweets(a1 int,a2 int,a3 int,a4 int,a5 int,a6 int)ENGINE=InnoDB;
Query OK, 0 rows affected (0.66 sec)
- 1
- 2
- 3
- 4
- 5
1.7 重复步骤1.2-1.3
修改配置文件my.ini在[mysqld]下添加/修改innodb_force_recovery=6
1.8 启动mysql服务，查看表结构，发现表结构已经恢复
mysql> desc weibo_tweets;
+-------------+---------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------+------+-----+-------------------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| uid | varchar(10) | NO | | NULL | |
| content | varchar(1000) | YES | | NULL | |
| pub_time | varchar(20) | YES | | NULL | |
| tool | varchar(50) | YES | | NULL | |
| create_time | datetime | YES | | CURRENT_TIMESTAMP | |
+-------------+---------------+------+-----+-------------------+----------------+
6 rows in set, 1 warning (0.01 sec)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
导出表结构，在命令提示符下输入
mysqldump -uroot -proot data_rec weibo_twets > e:\tweets.sql
在.sql文件中找到建表语句。
或者也可以用数据库管理软件如navicat中找到这张表，在对象信息中复制下DDL选项卡里的内容。
1.9 停止mysql服务，修改配置文件my.ini
修改innodb_force_recovery=0或者直接注释掉。
2.0 启动mysql服务，删掉这张表，用获得的建表语句新建表
至此，表结构已经完全恢复。
二、恢复表数据
2.1 分离表空间
使当前.ibd的数据文件和.frm分离。
ALTER TABLE weibo_tweets DISCARD TABLESPACE;
2.2 复制备份的.ibd文件覆盖新的表数据
2.3 重新建立新的连接
ALTER TABLE weibo_tweets IMPORT TABLESPACE;
至此，数据恢复完毕。
三、后话
网上有人用vim以16进制打开.ibd文件，查看表空间ID后，将备份.ibd文件覆盖后修改表空间ID为新的.ibd文件的ID，也可以重新建立数据文件和表空间的连接恢复数据。
Windows环境下可以用WinHex达成此目的，听起来也是可行的。
我是一介懒人就不尝试了，有兴趣余力的大佬可以试试。
转自：
https://blog.csdn.net/zhchs2012/article/details/79013951