MySQL表休闲后丢失/损坏
昨天我把我的MySQL数据库转储到一个SQL文件，并重命名ibdata1文件。 然后我重新创build并导入了SQL文件，并将新的ibdata1文件移到我的MySQL数据目录中，删除了旧的。
我以前没有问题，但是这一次是不对的。 当我检查（个人，而不是MySQLconfiguration）数据库，他们都在那里，但他们是空的…sorting。 数据目录中仍然有.ibd文件，其中包含正确的内容，我可以查看数据库中的表列表 ，但不能查看表格本身。 （我有每个表启用文件，并使用InnoDB作为默认的一切。）
例如与urls数据库及其URL表，我可以成功打开mysql.exe或phpMyAdmin，并use urls; 。 我甚至可以show tables; 看到预期的表格，但是当我试图describe urls; 或select * from urls; ，它抱怨表不存在（即使它刚刚列出）。 （MySQL Administrator列出了数据库，但是甚至没有列出这些表，这表明这些数据库是完全空的。）
现在的问题是，我已经删除了SQL文件（即使在刷硬盘后也无法恢复）。 所以我试图找出一种方法来修复这些数据库/表。 我不能使用表修复function，因为它抱怨表不存在，我不能转储他们，因为它再次抱怨表不存在。
- 文件损坏问题AIX jFS2
- 逃生windows修复安装并启动在正常启动？
- 防止磁盘损坏数据的最佳做法
- 赢2003服务器：损坏的文件夹/可用磁盘空间
- 如何testing用户configuration文件的完整性？
就像我所说的，数据本身仍然存在于.ibd文件中，并且表名存在。 我只需要一种方法让MySQL知道这些表存在于数据库中（我可以使用hex编辑器在ibdata1文件中find有问题的表的列名）。
任何想法如何我可以修复这种types的腐败？ 我不介意卷起袖子，挖掘，并采取一堆步骤来解决它。
非常感谢。
那么我尝试了一堆东西，并研究了一堆命令，开关和结构（毫不奇怪，MySQL文档是最有用的，如果广泛的针/干草堆）。 最后我的一些技巧奏效了（事实certificate，其他人也想到了同样的技巧，虽然我没有看到两个主要部分 – 恢复表结构和恢复数据 – 在一个地方，所以我把它们张贴在一起这里）。
我所要做的就是重新创buildIBDATA1文件。 不幸的是，在运行守护进程检测数据库（目录）的时候，它并没有拿起Innodb里面的表（IBD / FRM文件）。 所以我做的是：
- 清空数据目录（或移动原始文件并创build一个空的目录）
- 运行守护进程，让它创build一个新的，空的IBDATA1文件
- 使用
…\MySQL\share的SQL脚本导入系统表 - 创build一个虚拟数据库和同名的表
- 复制原始的FRM文件
- 使用
DESCRIBE或更好，SHOW TABLE CREATE来提取表结构 - 接下来，我在桌面上使用了
DISCARD TABLESPACE - 复制原始的IBD文件
- 然后我用
IMPORT TABLESPACE - 最后，我用
innodb-force-recovery=6重新运行守护进程 - 我运行
mysqldump来提取结构和数据
当然，这并不总是顺利的。 有些表很好，但有些需要在SHOW TABLE CREATE之后删除表和数据库，然后在尝试导入数据之前使用它重新创build表。 其他人甚至没有工作到那么远，我不得不手动从FRM文件中使用hex编辑器获取列的注释和名称（尽pipe确定数据types和属性，密钥等是什么是一个废话，射击）。 另外，守护进程和客户端重新启动的次数也很多。
（我仍然在寻找一个能够直接parsingFRM / IBD文件的工具（或者至less可以从FRM文件中显示表格结构），但是看起来好像没有人反过来对它们进行“反向工程”，即使它是开源的而且这些文件格式是公开的，似乎每个人都使用官方的MySQL工具而自满，从而为数据恢复公司和专有/商业工具创造了一个很好的机会。
关键是始终使用绝对最低限度（例如只有MYSQL目录 – 即系统表）。 不幸的是，虽然这意味着事情会简单化并且更容易处理，但也意味着一次只能恢复一张表 – 这对我来说不是什么大事，但对于一些人来说可能是这样。
无论如何，在过去几天我看到的互联网上的许多MySQL恢复页面中，有一小部分是非常有用的，一旦我把我的历史挖掘出来，我就会添加它们。
希望这可以帮助其他人在类似的情况。
能够列出所有表格和数据库通常意味着* .frm文件在那里。 这并不意味着他们有任何数据。 你有没有尝试启动你的mysqld进程强制innodb恢复 ？ 如果没有，请尝试一下，是的，mysql日志在启动时会说什么？
完成之后：永远不要尝试再次使用这样的备份。