mysql數據表文件損壞（mysql表損壞的常見病因）

本文目錄一覽：

• 1、如何修復MYSQL資料庫因斷電造成的數據損壞
• 2、mysql的表壞了怎麼修復啊？
• 3、怎麼查看mysql資料庫中的表是否損壞

如何修復MYSQL資料庫因斷電造成的數據損壞

修復MYSQL資料庫因斷電造成的數據損壞

在使用MySQL資料庫的時候，都碰到過因斷電造成資料庫損壞的情況，大家都知道，斷電或非正常關機是導致MySQL資料庫出現錯誤最常見的原因，如何恢復MySQL資料庫是大家都非常頭痛的問題。目前有方法可以幫助大家恢復損壞的MySQL資料庫嗎？

當用戶出現斷電造成的MySQL資料庫丟失損壞時，如果能進入MySQL軟體，但是提示錯誤信息，用戶可以通過「系統維護」—「資料庫壓縮修復」，壓縮下資料庫（有些軟體在「系統設置」—「系統維護」—「資料庫備份\恢復」中），這種方法只適合一小部分的資料庫故障修復，功能性並不高。

現在網路上有兩種比較推薦使用的MySQL資料庫恢復方法，一種方法使用MySQL(和PHP搭配之最佳組合)的check

table和repair

table

的sql語句，另一種方法是使用MySQL(和PHP搭配之最佳組合)提供的多個myisamchk，

isamchk數據檢測恢復工具。在很多用戶看來，這兩個方法都比較複雜，並不適合大多數的用戶使用。另外，這兩種方法並不能有效的恢復MySQL資料庫，可能還會造成資料庫被進一步損壞，造成大家無法挽回的損失。根據以上幾個原因，這兩種MySQL資料庫恢復方法並不建議大家使用。

。

資料庫被損壞分以下幾種情況：

1、嚴重損壞

2、輕度損壞

3、有些表被損壞或有些表的部分記錄被損壞

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 ，使得資料庫被掛起而不需要回滾，然後捨棄導致失控回滾的表。

網上找的

怎麼查看mysql資料庫中的表是否損壞

可以使用語句檢查表。如果結果的msg_text部分是好的，那麼你的表是健康的。反之，則表明mysql資料庫中的表有損壞。另外有些厲害的高手一額可以通過運行腳本來檢測。

MyISAM 表可以採用以下方法進行修復 ：使用 reapair table 或myisamchk 來修復。如果修復無效，採用備份恢復表。

階段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並且嘗試重建索引文件。