问题描述
其实在之前的开发维护过程中就已经碰到过了这个问题，明明没有人为的drop删除操作，可是某张表却在数据库中找不着了，用create语句重新创建被告知存在同名表，但是drop table又说找不着这张表，甚至连drop database都会报错can't rmdir .xxx\
先前的解决方案
前几次都是按照以下步骤解决这个问题
1, 用service mysqld stop停止数据库进程
2, 进入/var/lib/mysql/目录下用rm -rf xxx/清空报错数据库目录下的所有文件
3, service mysqld start重启数据库
4, 再次drop databse然后重建数据库与表格
虽然依靠migration脚本可以很方便的重建出错数据库和表格，但是出了问题的表格数据无法进行备份，难以恢复，这种解决方案治标不治本，而且对数据库的改动过于庞大
后来的解决方案
直到最近又出现了相同的问题，终于决定要找出问题的根源，通过网上查找资料得知出现这类怪异的问题一定一定要先看日志找到报错信息，再根据详细的报错信息查找解决方案，之前都是根据mysql服务端抛出给客户端的错误码到网上查找解决方案的，但是其实有很多种不同的因素能够导致这个错误码出现所以之前找到的解决方案都不适用于我的情况，直到在/var/log/mysqld.log错误日志中看到以下两条记录：
image.png
然后将其复制粘贴到网上进行搜索，终于在一篇博客中找到了最终的解决方法：
好好的表在MySQL5.6 就Table xxx.xxx dont't exist了
总结教训
不止mysql，其实在使用其他类似工具的时候，出了错都要先看日志，一定把日志的作用重视起来！
