起因：公司内部使用的一个考勤系统（tomcat+mysql）由于使用的频率并不高，程序也并没有考虑需要进行数据定期备份（想起来了就备份下）。

前几天由于服务没有正常的关闭服务器的情况下导致无法正常使用数据库。

现象：出现数据库启动状态（netstat 查看有3306）无法连接数据库。查看安装目录bin下面的可执行文件不见了。

处理方式：卸载数据库，进行重新安装，恢复1个多月前的数据脚本。但是安装过后导致很多重要数据丢失了，于是就必须要进行恢复了。


恢复方式：由于mysql 安装过程对如果上次不卸载干净就没有无法重新安装的情况（自己多次卸载重新安装都存在问题）于是安装了导致之前的数据库文件都不存在了
能找到也是一个多月上的数据库文件了。 而且都是无法正常替换的（数据目录下的FRM这几个文件）。
在网上找了恢复的相关资料很多都是说使用恢复文件的找回误删除的文件。恢复的大多数文件都是乱码的。于是这个好像就到了无法恢复的地步了。但是这个数据难道就不能通过那个借个FRM 的数据库文件找回来的吗？？但是过了1天无意间发现安装mysql 的存储路径不应该和安装目录一致呀（但是data 目录的确就在安装目录下了呀）。我在自己电脑上安装mysql 尝试着去恢复文件看看。 但是一次无法替换成功。
而且当时创建了一个数据文件可是也没有发现出现对应的文件夹，神了呀。
于是嫌弃麻烦就索性直接把自己项目的数据表结构文件发到了 mysql的数据库目录下了，就是看到有个提示也没有注意的观察直接就给覆盖了。尝试去登录mysql 数据库。发现咋个就登录不上了。猛地一想，自己系统里面也有user 这个表。 这下子好了。发现替换好像也无法通过crtl+z 恢复了。没有办法就只有重新安装了，想了想好像要删除好多东西的呢。通过之前的多次重装mysql 的经验告诉我。programData 下面会有数据文件也要同时删除。

---

呀。想到这里在服务器上的数据库是不是也存在programData 里面的。 我马上查看服务器上的目录下，还真这些文件。而且看最近更改的时间来看看是最近几天的。于是马上把文件尝试拷到自己电脑上进行恢复。通过复制data 目录的方式。（注意这里需要的不光是数据对应的目录下的文件，还包含2个log 文件有点大。）
这里的xx-log.idb 主要是记录数据的数据记录。如果不考这两个文件通过工具是能看到表的，但是无法查看数据提示 xx table not exists 。(这里恢复的时候最好是数据库版本保持一致)

总结
1.数据库的数据要及时备份。
2.mysql 默认安装方式 会在 programData 里面存放数据库文件。
3.尽量不要使用 shift+del 的方式删除文件。否则有些时候会与多做很多的事