4.6.3.3 myisamchk の修復オプション

myisamchk は、テーブルの修復操作 (--recover オプションまたは --safe-recover オプションなどのオプションが指定された場合に実行される操作) のために次のオプションをサポートします。

  • --backup, -B

    .MYD ファイルのバックアップを file_name-time.BAK として作成します。

  • --character-sets-dir=path

    文字セットがインストールされているディレクトリ。セクション10.5「文字セットの構成」を参照してください。

  • --correct-checksum

    テーブルのチェックサム情報を修正します。

  • --data-file-length=len, -D len

    データファイルの最大長 (データファイルがいっぱいになったとき再作成する場合)。

  • --extend-check, -e

    データファイルからできるかぎりの行をリカバリしようとする修復を実行します。これは通常、ガベージ行も大量に検出します。このオプションは、切羽詰まった状況でなければ使用しないでください。

    このオプションの説明は、テーブルチェックオプションも参照してください。

    出力形式の説明は、セクション4.6.3.5「myisamchk によるテーブル情報の取得」を参照してください。

  • --force, -f

    中止せず、古い中間ファイル (tbl_name.TMD のような名前のファイル) を上書きします。

  • --keys-used=val, -k val

    myisamchk では、オプション値はどのインデックスを更新するかを示すビット値です。オプション値の各バイナリビットがテーブルインデックスに対応します。最初のインデックスはビット 0 です。オプション値が 0 の場合、すべてのインデックスの更新が無効になります。より高速な挿入を行うために使用できます。無効化されたインデックスは myisamchk -r を使用して再度有効化できます。

  • --no-symlinks, -l

    シンボリックリンクをたどりません。通常、myisamchk はシンボリックリンクが示すテーブルを修復します。MySQL 4.0 以降のバージョンでは修復操作中にシンボリックリンクを削除しないため、このオプションは 4.0 には存在しません。

  • --max-record-length=len

    myisamchk が指定された長さより大きい行を保存するためにメモリーを割り当てられない場合、行をスキップします。

  • --parallel-recover, -p

    -r および -n と同じテクニックを使用しますが、異なるスレッドを使用してすべてのキーを並行して作成します。これはベータ品質のコードです。自己責任でご使用ください。

  • --quick, -q

    データファイルではなくインデックスファイルのみを変更することで、より高速な修復を実現します。このオプションを 2 回指定することで、重複キーの場合に myisamchk を使用して強制的に元のデータファイルを変更させることができます。

  • --recover, -r

    一意ではない一意なキー以外のすべてを修復できる修復を実行します (これは MyISAM テーブルではきわめてまれなエラーです)。テーブルをリカバリするには、このオプションをまず試してください。--safe-recover は、myisamchk が、--recover を使用してテーブルをリカバリできないとレポートする場合のみ使用するようにしてください。(非常にまれではありますが、--recover が失敗した場合、データファイルはそのままです。)

    メモリー容量に余裕がある場合、myisam_sort_buffer_size の値を増やすようにしてください。

  • --safe-recover, -o

    すべての行を順に読み取り、検出された行に基づいてすべてのインデックスツリーを更新する古いリカバリ方法を使用して修復します。この方法は --recover よりも格段に遅くなりますが、--recover では対応できないいくつかのまれなケースに対応できます。また、このリカバリ方法は --recover よりもはるかに少ないディスクスペースを使用します。通常、まず --recover を使用して修復し、--recover が失敗した場合にかぎって --safe-recover を使用するようにしてください。

    メモリー容量に余裕がある場合、key_buffer_size の値を増やすとよいでしょう。

  • --set-character-set=name

    テーブルインデックスで使用する文字セットを変更します。このオプションは、MySQL 5.0.3 で --set-collation に置換されました。

  • --set-collation=name

    テーブルインデックスのソートに使用する照合順序を指定します。照合順序名の初めの部位が文字セット名を示しています。

  • --sort-recover, -n

    一時ファイルのサイズが非常に大きくなっても、キーの解決にソートを使用することを myisamchk に強制します。

  • --tmpdir=path, -t path

    一時ファイルの保存に使用するディレクトリのパス。設定しない場合、myisamchkTMPDIR 環境変数の値を使用します。--tmpdir に、一時ファイルの作成にラウンドロビン方式で順に使用する、ディレクトリパスのリストを設定できます。ディレクトリ名の間の区切り文字は、Unix ではコロン (:)、Windows ではセミコロン (;) です。

  • --unpack, -u

    myisampack でパックされたテーブルをアンパックします。


User Comments
  Posted by on November 18, 2003
This information doesn't cover what to do when myisamchk reports the following error:

myisamchk: error: '<table>' doesn't have a correct index definition. You need to recreate it before you can do a repair
  Posted by Tristan Bailey on June 29, 2004
This is what i used after I got the error:
"doesn't have a correct index definition. You need to recreate it before you can do a repair"

Login to command line mysql

mysql> CHECK TABLE stats;
+--------------------+-------+----------+--------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+--------------------+-------+----------+--------------------------------------------+
| NEW.stats | check | warning | Table is marked as crashed |
| NEW.stats | check | error | Wrong bytesec: 0-0-0 at linkstart: 1204660 |
| NEW.stats | check | error | Corrupt |
+--------------------+-------+----------+--------------------------------------------+
3 rows in set (0.15 sec)

mysql> REPAIR TABLE stats;
+--------------------+--------+----------+--------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+--------------------+--------+----------+--------------------------------------------+
| NEW.stats | repair | info | Wrong bytesec: 0-0-0 at 1204660; Skipped |
| NEW.stats | repair | warning | Number of rows changed from 10517 to 10487 |
| NEW.stats | repair | status | OK |
+--------------------+--------+----------+--------------------------------------------+
3 rows in set (0.22 sec)

Thanks to a google search I found this tip form Kevin W. Paulisse on http://support.discusware.com/forum/messages/7/14583.html?1037883255. "it appears that this error code is associated with a crash of the MySQL database, where the table (in this case, the search table) is marked as needing repair."

Now the table is up and running again, with all the data
  Posted by on June 7, 2006
Under the --keys-used=val option it should be noted that doing a myisamchk -r will not reactivate the keys until after a mysqladmin flush-tables has been executed.
  Posted by Brian Sperlongano on January 25, 2008
If you're trying to recover a HUGE table (10-100 million or more records) for which the .MYI file has become lost, here's one way to do it more quickly:

1. Run REPAIR TABLE ... USE_FRM, but kill it as soon as the .MYI is created

2. Stop any running copy of mysqld

3. Run myisamchk using one of the recover options
  Posted by Humberto Silva on January 20, 2010
If you're dealing with the error:

Incorrect key file for table '[...].MYI'; try to repair it

After having run out of space on disk, make sure you have the following:

1. Enough free space left on the machine
2. Run the repair: myisamchk -r [...].MYI
3. Restart mysqld (this could/should be done before the repair and, in my case, was needed so that the mysqld "knew" it had more free space to work)

Humberto Silva
Sign Up Login You must be logged in to post a comment.