MySQLが4.1から5.1へのアップグレード後に夜間にテーブルを修復するのはなぜですか？

私はバックアップのために毎晩エクスポートするギガバイトサイズのMySQL MyISAMテーブルを持っています。これは数時間、「キーキャッシュで修復」に入ります。MySQLが4.1から5.1へのアップグレード後に夜間にテーブルを修復するのはなぜですか？

これは、MySQLを4.1から5.1にアップグレードした後に始まりました（私は4.1から5.0から5.1へのステップでそれを行いました）。 5.1を非難するのは不思議そうだが、サーバー上の唯一の変更だ。

このサーバーには、この問題が発生していない他のテーブルがたくさんありますが、半分ほどはありません。

"create table like"と "blah select * from"で表を置き換えようとしましたが、これは何も変更されていません。これは輸出入と同じくらい良いのでしょうか？

私はフルテキストインデックスを完全に削除して、この動作を停止させたり、少なくとも修復を高速化したりして、成功することはありませんでした。

また、myisamchkを使用して手動で修復しても、動作は変更されませんでした。

これは低アクティビティデータベースであり、1時間あたりの書き込みと読み込みがほとんどありません。

誰も私にこれがどうして起こっているのか、さらに詳しい情報を得るためにデバッグするかもしれないことについて私に洞察を与えることができますか？

より多くの研究のためにこれらのリンクを追加：

が、私はなぜ私の元の質問に答えていないことがmyisam_max_sort_file_size

をチェックする必要があるように見えますそれは最初の場所で毎晩修復する必要があります。

2011-09-15 ck_

これを見てください - それはhttp://stackoverflow.com/questions/1067367/how-to-avoid関連している可能性があり-repair-with-keycache –

これはhttp://bugs.mysql.com/ –

に報告しなければならないと思います。これは偶然にもDebianインストールではありませんか？ – jishi

は

あなたは問題がある場合、また、あなたが（mysqlのの外に、シェルで）これを実行することができます REPAIR TABLE mytable USE_FRM EXTENDED

を行うCHECK TABLE mytable FOR UPGRADE

を実行してみてください

myisamchk --force --recover --key_buffer_size=512M --sort_buffer_size=64M --read_buffer_size=8M --write_buffer_size=8M /path/to/datadir/*/*.MYI

（あなたがMYIへのパスを指定する必要があります - インデックスファイル）

2011-09-15 07:35:30 Jonathan

答えて