mysql 文件损害_mysql文件损坏恢复记录

问题原因：

发现服务器的mysql版本较低，会存在给骇客攻击的漏洞。需要升级mysql版本到5.7.30，于是将数据库升级到了5.7.30。之后发现界面无法显示数据，排查原因后发现某张表不存在，大致定性为数据库升级导致数据库文件损坏。

前置条件：

1.损坏的表，下文将该表成为a表

2.mysql的数据目录中有idb，和frm文件

3.mysql命令行无法创建a表，显示a表已存在

4.show tables无法显示a表，show create table a也是显示a表不存在

5.因为a表比较特殊，a表的数据来源是定时从其他表里面计算出来的，其他表的数据都在，所以只要能删除并重新创建就可以解决问题。没有存在数据恢复的问题

6.以下验证都是在mysql innodb中解决的

处理步骤：

1.查找各种资料，反复跳到不同的网站查询。最后还是Stack Overflow比较靠谱，提出了一个新的概念，孤表 orphan table，我的理解就是缺失了idb，frm之类的文件，但是ibdata1中可能还缓存着已经被删除的表。

2.按照Stack Overflow中的介绍将idb，frm从mysql数据目录复制出来到其他目录，并删除了原来数据目录中的idb，frm数据。再去mysql 命令行中删除a表，如果能删除成功就完成了。实际情况发现移除了idb，frm之后根本就不显示a表了，但是依旧无法创建a表。

3.在2的基础上尝试了另一种方式，创建一个myisam引擎的a表，数据结构都和之前一致，然后在mysql命令行删除a表。结果是创建myisam的a表成功，删除也成功，但是无法创建innodb的a表。

并显示error：ERROR 1030 (HY000): Got error 168 from storage engine

4.从sof找到了跳转到mysql官网的解决方案：

innodb数据字典处理：

dev.mysql.com/doc/refman/…

最终是靠官网的innodb数据字典处理解决方案完成了：

具体操作步骤：

1.从其他数据库创建一个一模一样的表，将其他mysql数据目录的a表的frm文件给复制到当前数据库的数据目录

2.在当前数据库使用drop table命令

3.很关键的一步，重启mysql。这里官网没有写弄完要重启，实测后发现没重启之前依然无法创建a表，重启mysql之后可以。这里细节没有去探究是不是重启，mysql有初始化ibdata1之类的操作。但大致解决思路和方向是这样。

其他方式：

1.如果处理步骤中的4还是没有解决，可以尝试强制恢复innodb数据试试看，没有验证过，只是据说可用。

强制恢复innodb数据

dev.mysql.com/doc/refman/…

2.以上方式都失败了后，终极解决方案：修改代码，不在使用a表的名称，新建一张b表来代替。(没办法的办法，尽量不要走到这一步)