1.表?yè)p壞的原因分析以下原因是導(dǎo)致mysql 表毀壞的常見(jiàn)原因：

1、 服務(wù)器突然斷電導(dǎo)致數(shù)據(jù)文件損壞。

2、 強(qiáng)制關(guān)機(jī)，沒(méi)有先關(guān)閉mysql 服務(wù)。

3、 mysqld 進(jìn)程在寫(xiě)表時(shí)被殺掉。

4、 使用myisamchk 的同時(shí)，mysqld 也在操作表。

5、 磁盤(pán)故障。

6、 服務(wù)器死機(jī)。

7、 mysql 本身的bug 。

2.表?yè)p壞的癥狀一個(gè)損壞的表的典型癥狀如下：

1 、當(dāng)在從表中選擇數(shù)據(jù)之時(shí)，你得到如下錯(cuò)誤：

Incorrect key file for table: '...'. Try to repair it

2 、查詢不能在表中找到行或返回不完全的數(shù)據(jù)。

3 、Error: Table 'p' is marked as crashed and should be repaired 。

4 、打開(kāi)表失敗： Can't open file: ‘×××.MYI' (errno: 145) 。

5 、

3.預(yù)防 MySQL 表?yè)p壞可以采用以下手段預(yù)防m(xù)ysql 表?yè)p壞：

1 、定期使用myisamchk 檢查MyISAM 表(注意要關(guān)閉mysqld )，推薦使用check table 來(lái)檢查表(不用關(guān)閉mysqld )。

2 、在做過(guò)大量的更新或刪除操作后，推薦使用OPTIMIZE TABLE 來(lái)優(yōu)化表，這樣既減少了文件碎片，又減少了表?yè)p壞的概率。

3 、關(guān)閉服務(wù)器前，先關(guān)閉mysqld (正常關(guān)閉服務(wù)，不要使用kill -9 來(lái)殺進(jìn)程)。

4 、使用ups 電源，避免出現(xiàn)突然斷電的情況。

5 、使用最新的穩(wěn)定發(fā)布版mysql ，減少mysql 本身的bug 導(dǎo)致表?yè)p壞。

6 、對(duì)于InnoDB 引擎，你可以使用innodb_tablespace_monitor 來(lái)檢查表空間文件內(nèi)文件空間管理的完整性。

7 、對(duì)磁盤(pán)做raid ，減少磁盤(pán)出錯(cuò)并提高性能。

8 、數(shù)據(jù)庫(kù)服務(wù)器最好只跑mysqld 和必要的其他服務(wù)，不要跑其他業(yè)務(wù)服務(wù)，這樣減少死機(jī)導(dǎo)致表?yè)p壞的可能。

9 、不怕萬(wàn)一，只怕意外，平時(shí)做好備份是預(yù)防表?yè)p壞的有效手段。

4.MySQL 表?yè)p壞的修復(fù)MyISAM 表可以采用以下步驟進(jìn)行修復(fù) ：

1、 使用 reapair table 或myisamchk 來(lái)修復(fù)。

2、 如果上面的方法修復(fù)無(wú)效，采用備份恢復(fù)表。

具體可以參考如下做法：

階段1 ：檢查你的表

如果你有很多時(shí)間，運(yùn)行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s (沉默)選項(xiàng)禁止不必要的信息。

如果mysqld 服務(wù)器處于宕機(jī)狀態(tài)，應(yīng)使用--update-state 選項(xiàng)來(lái)告訴myisamchk 將表標(biāo)記為' 檢查過(guò)的' 。

你必須只修復(fù)那些myisamchk 報(bào)告有錯(cuò)誤的表。對(duì)這樣的表，繼續(xù)到階段2 。

如果在檢查時(shí)，你得到奇怪的錯(cuò)誤( 例如out of memory 錯(cuò)誤) ，或如果myisamchk 崩潰，到階段3 。

階段2 ：簡(jiǎn)單安全的修復(fù)

注釋：如果想更快地進(jìn)行修復(fù)，當(dāng)運(yùn)行myisamchk 時(shí)，你應(yīng)將sort_buffer_size 和Key_buffer_size 變量的值設(shè)置為可用內(nèi)存的大約25% 。

首先，試試myisamchk -r -q tbl_name(-r -q 意味著“ 快速恢復(fù)模式”) 。這將試圖不接觸數(shù)據(jù)文件來(lái)修復(fù)索引文件。如果數(shù)據(jù)文件包含它應(yīng)有的一切內(nèi)容和指向數(shù)據(jù)文件內(nèi)正確地點(diǎn)的刪除連接，這應(yīng)該管用并且表可被修復(fù)。開(kāi)始修復(fù)下一張表。否則，執(zhí)行下列過(guò)程：

在繼續(xù)前對(duì)數(shù)據(jù)文件進(jìn)行備份。

使用myisamchk -r tbl_name(-r 意味著“ 恢復(fù)模式”) 。這將從數(shù)據(jù)文件中刪除不正確的記錄和已被刪除的記錄并重建索引文件。

如果前面的步驟失敗，使用myisamchk --safe-recover tbl_name 。安全恢復(fù)模式使用一個(gè)老的恢復(fù)方法，處理常規(guī)恢復(fù)模式不行的少數(shù)情況( 但是更慢) 。

如果在修復(fù)時(shí)，你得到奇怪的錯(cuò)誤( 例如out of memory 錯(cuò)誤) ，或如果myisamchk 崩潰，到階段3 。

階段3 ：困難的修復(fù)

只有在索引文件的第一個(gè)16K 塊被破壞，或包含不正確的信息，或如果索引文件丟失，你才應(yīng)該到這個(gè)階段。在這種情況下，需要?jiǎng)?chuàng)建一個(gè)新的索引文件。按如下步驟操做：

把數(shù)據(jù)文件移到安全的地方。

使用表描述文件創(chuàng)建新的( 空) 數(shù)據(jù)文件和索引文件：

復(fù)制代碼 代碼如下:

shell> mysql db_name

mysql> SET AUTOCOMMIT=1;

mysql> TRUNCATE TABLE tbl_name;

mysql> quit

如果你的MySQL 版本沒(méi)有TRUNCATE TABLE ，則使用DELETE FROM tbl_name 。

將老的數(shù)據(jù)文件拷貝到新創(chuàng)建的數(shù)據(jù)文件之中。(不要只是將老文件移回新文件之中；你要保留一個(gè)副本以防某些東西出錯(cuò)。)

回到階段2 。現(xiàn)在myisamchk -r -q 應(yīng)該工作了。(這不應(yīng)該是一個(gè)無(wú)限循環(huán))。

你還可以使用REPAIR TABLE tbl_name USE_FRM ，將自動(dòng)執(zhí)行整個(gè)程序。

階段4 ：非常困難的修復(fù)

只有.frm 描述文件也破壞了，你才應(yīng)該到達(dá)這個(gè)階段。這應(yīng)該從未發(fā)生過(guò)，因?yàn)樵诒肀粍?chuàng)建以后，描述文件就不再改變了。

從一個(gè)備份恢復(fù)描述文件然后回到階段3 。你也可以恢復(fù)索引文件然后回到階段2 。對(duì)后者，你應(yīng)該用myisamchk -r 啟動(dòng)。

如果你沒(méi)有進(jìn)行備份但是確切地知道表是怎樣創(chuàng)建的，在另一個(gè)數(shù)據(jù)庫(kù)中創(chuàng)建表的一個(gè)拷貝。刪除新的數(shù)據(jù)文件，然后從其他數(shù)據(jù)庫(kù)將描述文件和索引文件移到破壞的數(shù)據(jù)庫(kù)中。這樣提供了新的描述和索引文件，但是讓.MYD 數(shù)據(jù)文件獨(dú)自留下來(lái)了。回到階段2 并且嘗試重建索引文件。

InnoDB 表可以采用下面的方法修復(fù)：

如果數(shù)據(jù)庫(kù)頁(yè)被破壞，你可能想要用SELECT INTO OUTFILE 從從數(shù)據(jù)庫(kù)轉(zhuǎn)儲(chǔ)你的表，通常以這種方法獲取的大多數(shù)數(shù)據(jù)是完好的。即使這樣，損壞可能導(dǎo)致SELECT * FROM tbl_name 或者InnoDB 后臺(tái)操作崩潰或斷言，或者甚至使得InnoDB 前滾恢復(fù)崩潰。 盡管如此，你可以用它來(lái)強(qiáng)制InnoDB 存儲(chǔ)引擎啟動(dòng)同時(shí)阻止后臺(tái)操作運(yùn)行，以便你能轉(zhuǎn)儲(chǔ)你的表。例如：你可以在重啟服務(wù)器之前，在選項(xiàng)文件的[mysqld] 節(jié)添加如下的行：

[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允許的非零值如下。一個(gè)更大的數(shù)字包含所有更小數(shù)字的預(yù)防措施。如果你能夠用一個(gè)多數(shù)是4 的選項(xiàng)值來(lái)轉(zhuǎn)儲(chǔ)你的表，那么你是比較安全的，只有一些在損壞的單獨(dú)頁(yè)面上的數(shù)據(jù)會(huì)丟失。一個(gè)為6 的值更夸張，因?yàn)閿?shù)據(jù)庫(kù)頁(yè)被留在一個(gè)陳舊的狀態(tài)，這個(gè)狀態(tài)反過(guò)來(lái)可以引發(fā)對(duì)B 樹(shù)和其它數(shù)據(jù)庫(kù)結(jié)構(gòu)的更多破壞。

1 (SRV_FORCE_IGNORE_CORRUPT)

即使服務(wù)器檢測(cè)到一個(gè)損壞的頁(yè)，也讓服務(wù)器運(yùn)行著；試著讓SELECT * FROM tbl_name 跳過(guò)損壞的索引記錄和頁(yè)，這樣有助于轉(zhuǎn)儲(chǔ)表。

2 (SRV_FORCE_NO_BACKGROUND)

阻止主線程運(yùn)行，如果崩潰可能在凈化操作過(guò)程中發(fā)生，這將阻止它。

3 (SRV_FORCE_NO_TRX_UNDO)

恢復(fù)后不運(yùn)行事務(wù)回滾。

4 (SRV_FORCE_NO_IBUF_MERGE)

也阻止插入緩沖合并操作。如果你可能會(huì)導(dǎo)致一個(gè)崩潰。最好不要做這些操作，不要計(jì)算表統(tǒng)計(jì)表。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

啟動(dòng)數(shù)據(jù)庫(kù)之時(shí)不查看未完成日志：InnoDB 把未完成的事務(wù)視為已提交的。

6 (SRV_FORCE_NO_LOG_REDO)

不要在恢復(fù)連接中做日志前滾。

數(shù)據(jù)庫(kù)不能另外地帶著這些選項(xiàng)中被允許的選項(xiàng)來(lái)使用。作為一個(gè)安全措施，當(dāng)innodb_force_recovery 被設(shè)置為大于0 的值時(shí)，InnoDB 阻止用戶執(zhí)行INSERT, UPDATE 或DELETE 操作.

即使強(qiáng)制恢復(fù)被使用，你也可以DROP 或CREATE 表。如果你知道一個(gè)給定的表正在導(dǎo)致回滾崩潰，你可以移除它。你也可以用這個(gè)來(lái)停止由失敗的大宗導(dǎo)入或失敗的ALTER TABLE 導(dǎo)致的失控回滾。你可以殺掉mysqld 進(jìn)程，然后設(shè)置innodb_force_recovery 為3 ，使得數(shù)據(jù)庫(kù)被掛起而不需要回滾，然后舍棄導(dǎo)致失控回滾的表。

總結(jié)

以上是生活随笔為你收集整理的mysql 表损坏_MYSQL数据表损坏的原因分析和修复方法小结(推荐)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。