問(wèn)題描述
其實(shí)在之前的開(kāi)發(fā)維護(hù)過(guò)程中就已經(jīng)碰到過(guò)了這個(gè)問(wèn)題粘招，明明沒(méi)有人為的drop刪除操作脏嚷，可是某張表卻在數(shù)據(jù)庫(kù)中找不著了各淀，用create語(yǔ)句重新創(chuàng)建被告知存在同名表妇穴，但是drop table又說(shuō)找不著這張表灸姊，甚至連drop database都會(huì)報(bào)錯(cuò)can't rmdir .xxx\
先前的解決方案
前幾次都是按照以下步驟解決這個(gè)問(wèn)題
1, 用service mysqld stop停止數(shù)據(jù)庫(kù)進(jìn)程
2, 進(jìn)入/var/lib/mysql/目錄下用rm -rf xxx/清空?qǐng)?bào)錯(cuò)數(shù)據(jù)庫(kù)目錄下的所有文件
3, service mysqld start重啟數(shù)據(jù)庫(kù)
4, 再次drop databse然后重建數(shù)據(jù)庫(kù)與表格
雖然依靠migration腳本可以很方便的重建出錯(cuò)數(shù)據(jù)庫(kù)和表格拱燃，但是出了問(wèn)題的表格數(shù)據(jù)無(wú)法進(jìn)行備份，難以恢復(fù)力惯，這種解決方案治標(biāo)不治本碗誉，而且對(duì)數(shù)據(jù)庫(kù)的改動(dòng)過(guò)于龐大
后來(lái)的解決方案
直到最近又出現(xiàn)了相同的問(wèn)題，終于決定要找出問(wèn)題的根源夯膀，通過(guò)網(wǎng)上查找資料得知出現(xiàn)這類(lèi)怪異的問(wèn)題一定一定要先看日志找到報(bào)錯(cuò)信息诗充，再根據(jù)詳細(xì)的報(bào)錯(cuò)信息查找解決方案，之前都是根據(jù)mysql服務(wù)端拋出給客戶(hù)端的錯(cuò)誤碼到網(wǎng)上查找解決方案的诱建，但是其實(shí)有很多種不同的因素能夠?qū)е逻@個(gè)錯(cuò)誤碼出現(xiàn)所以之前找到的解決方案都不適用于我的情況蝴蜓，直到在/var/log/mysqld.log錯(cuò)誤日志中看到以下兩條記錄：
然后將其復(fù)制粘貼到網(wǎng)上進(jìn)行搜索，終于在一篇博客中找到了最終的解決方法：
好好的表在MySQL5.6 就Table xxx.xxx dont't exist了
總結(jié)教訓(xùn)
不止mysql俺猿，其實(shí)在使用其他類(lèi)似工具的時(shí)候茎匠，出了錯(cuò)都要先看日志，一定把日志的作用重視起來(lái)押袍！
