現象：數據庫除了查詢以外的其他操作都失敗，報錯信息為：got error 28 from storage engin
原因：執行df命令，看到系統根目錄（/）的剩余空間是0，使用率達到了100%，原來是系統沒有任何空間了。
查找罪魁禍首：
1、查找下，數據主要“堆積”在哪裡
cd /
du -m --max-depth=1 -k
看到/usr用掉了絕大多數的空間，繼續深入進去
cd /usr
du -m --max-depth=1 -k
看到是local占了大頭
cd local
du -m --max-depth=1 -k
這次是mysql,果然沒錯，是mysql自己消耗掉了很大一部分磁盤空間，那到這個時候，猜也猜到，一定是MySQL下的data占用了空間，一看，果然是。
其實這個時候，症結已經差不多找出來了，但是這個時候會出現兩種情況，對於不同的情況，解決的辦法也不相同：
2、在data目錄，如果出現了很多MySQL-bin.000****的文件，而且占用空間很大，那這裡就要處理下。
mysql-bin.000***文件是MySQL的操作日志文件，裡面記錄這這個數據庫所有的數據操作（插入，更新，刪除等）的記錄，而且如果沒有相關的管理，這些文件是不會自己刪除的，只會越來越多，最後把磁盤給塞滿。
其實，對於一般用途的MySQL數據庫，我們對數據恢復阿，歷史操作查找阿什麼都不會太在意，那麼這些日志文件保留太長時間的，意義也不大，還不如刪掉一些老的日志文件，來為系統留下大量的空間。
我們只要在配置文件/etc/my.cnf裡添加下面這一句就行了：expire_logs_days=n就行了，“n”就是保留最近“幾天”的日志信息，之前的就都刪掉。
3、如果不是2的問題，那我們可以故技重施，看看data下面是哪個數據庫的目錄占用空間過大，找到這個數據庫，cd進去，ll一下，可以看到這裡存放著這個數據庫的所有表信息，一般一個表由三個文件組成：
TABLENAME.frm： 表結構文件
TABLENAME.MYD： 表數據文件
TABLENAME.MYI：表結構和數據的索引文件
可以想到，如果一張表的記錄很多，那麼TABLENAME.MYD就一定會很大。
如果沒有其他辦法了，一定要刪除這個表的數據，數據庫才能恢復，那刪除的步驟如下：
刪除TABLENAME.MYD，再重建一個空的文件TABLENAME.MYD,數據庫重啟，登錄到MySQL，進入相應的數據庫，執行delete from TABLENAME，這樣就可以了。
