MYSQL資料表損壞的原因分析和修複方法小結(推薦)

1.表損壞的原因分析
以下原因是導致mysql 表毀壞的常見原因：
1、 伺服器突然斷電導致資料檔案損壞。
2、 強制關機，沒有先關閉mysql 服務。
3、 mysqld 進程在寫表時被殺掉。
4、 使用myisamchk 的同時，mysqld 也在動作表。
5、 磁碟故障。
6、 伺服器死機。
7、 mysql 本身的bug 。

2.表損壞的癥狀
一個損壞的表的典型癥狀如下：
1 、當在從表中選擇資料之時，你得到如下錯誤：
Incorrect key file for table: '...'. Try to repair it
2 、查詢不能在表中找到行或返回不完全的資料。
3 、Error: Table 'p' is marked as crashed and should be repaired 。
4 、開啟表失敗： Can't open file: ‘×××.MYI' (errno: 145) 。
5 、
3.預防 MySQL 表損壞
可以採用以下手段預防mysql 表損壞：
1 、定期使用myisamchk 檢查MyISAM 表（注意要關閉mysqld ），推薦使用check table 來檢查表（不用關閉mysqld ）。
2 、在做過大量的更新或刪除操作後，推薦使用OPTIMIZE TABLE 來最佳化表，這樣既減少了檔案片段，又減少了表損壞的機率。
3 、關閉伺服器前，先關閉mysqld （正常關閉服務，不要使用kill -9 來殺進程）。
4 、使用ups 電源，避免出現突然斷電的情況。
5 、使用最新的穩定發布版mysql ，減少mysql 本身的bug 導致表損壞。
6 、對於InnoDB 引擎，你可以使用innodb_tablespace_monitor 來檢查資料表空間檔案內檔案空間管理的完整性。
7 、對磁碟做raid ，減少磁碟出錯並提高效能。
8 、資料庫伺服器最好只跑mysqld 和必要的其他服務，不要跑其他商務服務，這樣減少死機導致表損壞的可能。
9 、不怕萬一，只怕意外，平時做好備份是預防表損壞的有效手段。
4.MySQL 表損壞的修複
MyISAM 表可以採用以下步驟進行修複 ：
1、 使用 reapair table 或myisamchk 來修複。
2、 如果上面的方法修複無效，採用備份恢複表。
具體可以參考如下做法：
階段1 ：檢查你的表
如果你有很多時間，運行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）選項禁止不必要的資訊。
如果mysqld 伺服器處於宕機狀態，應使用--update-state 選項來告訴myisamchk 將表標記為' 檢查過的' 。
你必須只修複那些myisamchk 報告有錯誤的表。對這樣的表，繼續到階段2 。
如果在檢查時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。
階段2 ：簡單安全的修複
注釋：如果想更快地進行修複，當運行myisamchk 時，你應將sort_buffer_size 和Key_buffer_size 變數的值設定為可用記憶體的大約25% 。
首先，試試myisamchk -r -q tbl_name(-r -q 意味著“ 快速復原模式”) 。這將試圖不接觸資料檔案來修複索引檔案。如果資料檔案包含它應有的一切內容和指向資料檔案內正確地點的刪除串連，這應該管用並且表可被修複。開始修複下一張表。否則，執行下列過程：
在繼續前對資料檔案進行備份。
使用myisamchk -r tbl_name(-r 意味著“ 復原模式”) 。這將從資料檔案中刪除不正確的記錄和已被刪除的記錄並重建索引檔案。
如果前面的步驟失敗，使用myisamchk --safe-recover tbl_name 。安全復原模式使用一個老的恢複方法，處理常規復原模式不行的少數情況( 但是更慢) 。
如果在修複時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。
階段3 ：困難的修複
只有在索引檔案的第一個16K 塊被破壞，或包含不正確的資訊，或如果索引檔案丟失，你才應該到這個階段。在這種情況下，需要建立一個新的索引檔案。按如下步驟操做：
把資料檔案移到安全的地方。
使用表描述檔案建立新的( 空) 資料檔案和索引檔案： 複製代碼 代碼如下:shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit

如果你的MySQL 版本沒有TRUNCATE TABLE ，則使用DELETE FROM tbl_name 。
將老的資料檔案拷貝到新建立的資料檔案之中。（不要只是將老檔案移回新檔案之中；你要保留一個副本以防某些東西出錯。）
回到階段2 。現在myisamchk -r -q 應該工作了。（這不應該是一個無限迴圈）。
你還可以使用REPAIR TABLE tbl_name USE_FRM ，將自動執行整個程式。
階段4 ：非常困難的修複
只有.frm 描述檔案也破壞了，你才應該到達這個階段。這應該從未發生過，因為在表被建立以後，描述檔案就不再改變了。
從一個備份恢複描述檔案然後回到階段3 。你也可以恢複索引檔案然後回到階段2 。對後者，你應該用myisamchk -r 啟動。
如果你沒有進行備份但是確切地知道表是怎樣建立的，在另一個資料庫中建立表的一個拷貝。刪除新的資料檔案，然後從其他資料庫將描述檔案和索引檔案移到破壞的資料庫中。這樣提供了新的描述和索引檔案，但是讓.MYD 資料檔案獨自留下來了。回到階段2 並且嘗試重建索引檔案。
InnoDB 表可以採用下面的方法修複：
如果資料庫頁被破壞，你可能想要用SELECT INTO OUTFILE 從從資料庫轉儲你的表，通常以這種方法擷取的大多數資料是完好的。即使這樣，損壞可能導致SELECT * FROM tbl_name 或者InnoDB 後台操作崩潰或斷言，或者甚至使得InnoDB 前滾恢複崩潰。 儘管如此，你可以用它來強制InnoDB 儲存引擎啟動同時阻止後台操作運行，以便你能轉儲你的表。例如：你可以在重啟伺服器之前，在選項檔案的[mysqld] 節添加如下的行：
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允許的非零值如下。一個更大的數字包含所有更小數位預防措施。如果你能夠用一個多數是4 的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的資料會丟失。一個為6 的值更誇張，因為資料庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對B 樹和其它資料庫結構的更多破壞。
1 (SRV_FORCE_IGNORE_CORRUPT)
即使伺服器檢測到一個損壞的頁，也讓伺服器運行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程運行，如果崩潰可能在淨化操作過程中發生，這將阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢複後不運行交易回復。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入緩衝合併作業。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動資料庫之時不查看未完成日誌：InnoDB 把未完成的事務視為已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢複串連中做日誌前滾。
資料庫不能另外地帶著這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery 被設定為大於0 的值時，InnoDB 阻止使用者執行INSERT, UPDATE 或DELETE 操作.
即使強制恢複被使用，你也可以DROP 或CREATE 表。如果你知道一個給定的表正在導致復原崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗匯入或失敗的ALTER TABLE 導致的失控復原。你可以殺掉mysqld 進程，然後設定innodb_force_recovery 為3 ，使得資料庫被掛起而不需要復原，然後捨棄導致失控復原的表。