现象

找不到之前的表，用show tables能看到，但是select查询该表时报错该表不存在；
找到实际存储该表的位置查看frm文件和ibd文件均在；

结论

多半是表损坏

解决措施

先根据frm文件恢复表结构，再根据ibd文件恢复表数据

具体步骤

恢复表结构

新建一个数据库，再新建一张表，此表的名字和待恢复的表的名字一样，另外如果记得住损坏的表的字段数则保持新建表的字段数和之前一样，至于字段的具体类型无关紧要；
如果不知道之前表的字段数量可以先只增加一个字段，通过后面的报错确定损坏的表的字段数量；
停止mysql服务；
修改配置文件my.ini中的参数 innodb_force_recovery=6（没有则新增）附：此项参数各值的意义
1: (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的corrupt页
2: (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行，如主线程需要执行full purge操作，会导致crash
3: (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作
4: (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作
5: (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交
6: (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作
用之前表的frm文件替换掉新建的表的frm文件
删除或注释掉innodb_force_recovery=6，然后重启mysql服务，如果字段数量不一致会有相应报错，eg:[Warning] InnoDB: Table wangyi/songlyric contains 1 user defined columns in InnoDB, but 6 columns in MySQL. 如果有报错重复步骤2-6，不过在步骤2为新增字段数量，新增后的总数要与报错中发现的字段数量一致；
若没有报错，可以用desc查看表结构，确定是否与之前表结构一致，并通过三方工具查看建表语句便可恢复表结构；

恢复表数据

备份之前的表的ibd文件，然后在待恢复的数据库中删除掉ibd文件和frm文件，然后通过“恢复表结构”中获取到的建表语句新建待恢复表；
步骤1有可能是不会成功的，我恢复的时候就遇到了这个问题，新建表之后仍然报错表已存在，查看表位置目录，又自动多了个该表的ibd文件，WTF，还有这操作？凉凉，岂不是无解，就这个问题当时折磨了我老久，最终也没想出个所以来，只是怀疑还有存储该表的一些元数据信息。怎么办呢？搞不来，删库跑路。这当然是不可能的，删库倒是真的，不过备份了数据库，然后删除了ib_logfile0,iblogfile1,ibdata1这三个文件然后重新建了数据库，导入了新建的备份表，最后成功新建了之前损坏的表。现在想想应该也不需要删库，只需要干掉那三个文件就可以了，哎，说多了都是泪0.0；
解绑新建的ibd文件和frm文件：alter table 表名 discard tablespace;
停止数据库；
将备份的ibd文件替换掉新建的表的ibd文件；
启动数据库，建立ibd文件和frm文件的关系：alter table study import tablespace；

参考：https://chen2ha.blog.csdn.net/article/details/120930520