MySQL修復表的簡單分析

今天有個同事問我一個資料庫的問題，如果開始他就把環境細節全都告訴我，可能我就知難而退了。等我大體明白了問題之後，發現好像背景比我想的要複雜多了。這是一個遠端雲主機環境，windows系統，執行著MySQL,在查詢表時出現了問題，而且開發同事經過了repair也沒有修復，說會卡住沒有響應。

當然費了一點功夫，好容易連線到了這臺雲主機，發現問題似乎比我想的還要複雜一些。當然這是一個內部某一個團隊使用的一個環境，可能是確實需要用到環境，大家才不得不想辦法修復。

    環境是MySQL 5.5版本，檢視後臺日誌發現從8月份就開始有錯誤了，錯誤資訊如下：

161018 11:15:35 [ERROR] D:\websoft\mysql\bin\mysqld: Table '.\utestdb\test_forum_post' is marked as crashed and should be repaired
161018 11:15:36 [ERROR] D:\websoft\mysql\bin\mysqld: Table '.\utestdb\test_forum_post' is marked as crashed and should be repaired而且看日誌損壞的還不止一張表，我的注意力暫時先放在了出錯的表上。

如果使用show create table  test_forum_post或者desc test_forum_post都會丟擲錯誤。

mysql> show create table test_forum_post;
ERROR 145 (HY000): Table '.\utestdb\test_forum_post' is marked as crashed and should be repaired

更讓我有些膽戰心驚的是，我可以從後臺的日誌看到開發同事也嘗試了多次重啟MySQL服務。但是問題始終存在。

show create table 得不到資訊，而show table status得到的資訊也很有限，因為此時的儲存引擎顯示為NULL

他們用的是MyISAM,檢視了其它所有的表的儲存引擎，發現清一色都是MyISAM.所以我就可以基本斷定這個出問題的表也是MyISAM

對於MyISAM表修復，可以用myisamchk來做或者使用repair的方式都可以，當然發現又是碰到不少問題。

D:\websoft\mysql\bin>myisamchk.exe -of ..\data\utestdb\test_forum_post.MYI
這個命令執行下去，竟然彈出了一個視窗顯示程式崩潰，反覆嘗試都是如此。

使用repair命令來看，發現遲遲沒有返回，果斷停止。

肯定是哪裡漏掉了，我重新翻過頭來梳理問題。

檢視日誌發現之前有下面的一些輸出，看起來是磁碟空間的問題。

161219 18:07:09 [Warning] Disk is full writing '.\distoon\pre_common_block.TMD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
161219 18:07:09 [Warning] Retry in 60 secs. Message reprinted in 600 secs
161219 18:07:18 [ERROR] D:\websoft\mysql\bin\mysqld: Table '.\utestdb\test_forum_post' is marked as crashed and should be repaired

經過確認發現確實是磁碟空間導致，他們馬上清理預留出一些空間，然後讓我繼續幫忙修復，再次嘗試就沒有問題了。

先使用-of選項

D:\websoft\mysql\bin>myisamchk.exe -of ..\data\utestdb\test_forum_post.MYI
- recovering (with keycache) MyISAM-table '..\data\utestdb\test_forum_post.MYI'
Data records: 0
Data records: 55311

接著使用-r選項修復

D:\websoft\mysql\bin>myisamchk.exe -r ..\data\utestdb\test_forum_post.MYI
- recovering (with sort) MyISAM-table '..\data\utestdb\test_forum_post.MYI'
Data records: 55311
- Fixing index 1
- Fixing index 2
- Fixing index 3
- Fixing index 4
- Fixing index 5
- Fixing index 6
- Fixing index 7
- Fixing index 8

最後彙總檢查

D:\websoft\mysql\bin>myisamchk.exe  ..\data\utestdb\test_forum_post.MYI
Checking MyISAM file: ..\data\utestdb\test_forum_post.MYI
Data records:   55311   Deleted blocks:       0
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check data record references index: 3
- check data record references index: 4
- check data record references index: 5
- check data record references index: 6
- check data record references index: 7
- check data record references index: 8
- check record links再次檢視問題就不存在了。

當然如果嘗試使用repair也是可行的,比如修復表pre_common_member，輸出如下：

mysql> repair table pre_common_member;
+----------------------------+--------+----------+----------+
| Table                      | Op     | Msg_type | Msg_text |
+----------------------------+--------+----------+----------+
| utestdb.pre_common_member | repair | status   | OK       |
+----------------------------+--------+----------+----------+
1 row in set (1.64 sec)

為了把問題補充全面一些，我把問題略微改動下，即 使用myisamchk工具和check/repair命令有什麼區別呢.

首先myisamchk和repair只能修復MyISAM表，相比來說，myisamchk的輸出資訊要更詳細一些，優化，分析表的資訊都會輸出，repair則比較直接，repair無法修復InnoDB的表，否則會報出如下的錯誤。

The storage engine for the table doesn't support repair

check則同時支援MyISAM表和InnoDB表

其次myisamchk操作myisam表時必須保證表不能被使用，check/repair則可以線上操作。

問題解決了，不過想想問題的最開始撲朔迷離的場景，其實很多大問題的原因都是如此簡單。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2131074/，如需轉載，請註明出處，否則將追究法律責任。