web-dev-qa-db-ja.com

MySQL：＃126-テーブルの不正なキーファイル

MySQLクエリから次のエラーが発生しました。

#126 - Incorrect key file for table

このテーブルのキーも宣言していませんが、インデックスはあります。誰が何が問題になるのか知っていますか？

mysqlmysql-error-126
105
Brian

これが起こるたびに、それは私の経験では完全なディスクでした。

編集

また、ramdiskが構成されている場合に大きなテーブルを変更するようなことをするときに、これが完全なramdiskによって引き起こされる可能性があることにも注意する価値があります。サイズを大きくできない場合は、ramdisk行を一時的にコメントアウトして、このような操作を許可できます。

157
Monsters X

まず、キーとインデックスはMySQLの同義語であることを知っておく必要があります。 CREATE TABLE Syntax に関するドキュメントを見ると、以下を読むことができます：

KEYは、通常INDEXの同義語です。キー属性PRIMARY KEYは、列定義で指定された場合、ちょうどKEYとして指定することもできます。これは、他のデータベースシステムとの互換性のために実装されました。

現在、発生しているエラーの種類は、次の2つの原因が考えられます。

  • MySQLサーバーのディスクの問題
  • 破損したキー/テーブル

最初のケースでは、クエリに制限を追加すると一時的に問題が解決する場合があります。それがあなたのためにそれをするなら、おそらくあなたがしようとしているクエリのサイズに対して小さすぎるtmpフォルダを持っているでしょう。その後、tmpを大きくしたり、クエリを小さくしたりすることができます。 ;）

場合によっては、tmpは十分に大きいが、それでも満杯になることがあります。これらの状況では、手動でクリーンアップを行う必要があります。

2番目のケースでは、MySQLのデータに実際の問題があります。データを簡単に再挿入できる場合は、テーブルを削除または再作成して、データを再挿入することをお勧めします。できない場合は、 REPAIR table を使用して所定の場所にあるテーブルを修復してみてください。これは一般に時間がかかるプロセスであり、非常に失敗する可能性があります。

完全なエラーメッセージを見てください：

テーブル 'FILEPATH.MYI'のキーファイルが正しくありません。修理しよう

メッセージに、修復を試みることができると記載されています。また、取得した実際のFILEPATHを見ると、次のことがわかります。

  • /tmp/#sql_ab34_23fのようなものであれば、クエリサイズのためにMySQLが一時テーブルを作成する必要があることを意味します。/tmpに保存し、/ tmpにその一時テーブル用の十分なスペースがないことを確認します。

  • 代わりに実際のテーブルの名前が含まれている場合は、このテーブルが破損している可能性が高いため、修復する必要があることを意味します。

問題のサイズが/ tmpであることがわかった場合は、修正のための同様の質問に対するこの回答を読んでください： MySQL、Error 126：Incorrect key file for table 。

34
snooze92

これらの指示に従うと、tmpディレクトリを再作成して問題を修正できました。

すべてのファイルシステムとそのディスク使用量を人間が読める形式で表示します。

df -h

/tmpでファイルが開いているプロセスを見つける

Sudo lsof /tmp/**/*

次に、/tmpと/var/tmpをアンマウントします。

umount -l /tmp
umount -l /var/tmp

次に、破損したパーティションファイルを削除します。

rm -fv /usr/tmpDSK

次に、素敵な新しいものを作成します。

/scripts/securetmp

Securetmp Perlスクリプトを編集することにより、tmpディレクトリのサイズを手動で設定できますが、スクリプトを実行するだけで、サーバー上のtmpディレクトリのサイズが約450MBから4.0GBに増加することに注意してください。

16
user387049

エラー＃126は通常、破損したテーブルを取得したときに発生します。これを解決する最善の方法は、修復を実行することです。この記事は役に立つかもしれません：

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

9
junmats

ft_min_Word_len = 2にmy.cnfを設定すると、このエラーが発生しました。これにより、フルテキストインデックスの最小ワード長がデフォルトの4から2になります。

テーブルを修復すると問題が修正されました。

3
jcampbell1

クエリで制限を使用してみてください。 @Monsters Xが言ったように、フルディスクが原因です。

数千のレコードがあったため、この問題に直面し、クエリの制限によって解決しました。うまく動作しています:)

1
Bajrang

/etc/my.cnfに移動し、tmpfsをコメントアウトします

#tmpdir=/var/tmpfs

これにより問題が修正されます。

別の回答で提案されたコマンドを実行しましたが、ディレクトリが小さい間は空だったため、スペースは問題になりませんでした。

/var/tmp$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
/var/tmpfs$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
1
BenD

私はこれが古いトピックであることを知っていますが、言及された解決策のどれも私のために働きませんでした。私は働いた他の何かをしました：

必要がある：

  1. mySQLサービスを停止します。
  2. Mysql\dataを開きます
  3. Ib_logfile0とib_logfile1の両方を削除します。
  4. サービスを再開する
1
Hyder B.

この問題を修正しました：

ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;

助けになるかもしれない

1
Sean
repair table myschema.mytable;
1
ThreaT

今、他の答えは私のためにそれを解決しました。同じクエリで列とインデックスの名前を変更すると、エラーが発生したことがわかりました。

動作しない：

-- rename column and rename index
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

動作（2ステートメント）：

-- rename column
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
-- rename index
ALTER TABLE `client_types`
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

これはMariaDB 10.0.20にありました。 MySQL 5.5.48で同じクエリを使用してもエラーはありませんでした。

0
bernie

私の問題は、不適切なクエリに起因していました。 FROMでテーブルを参照しましたが、SELECTでは参照されませんでした。

例：

   SELECT t.*,s.ticket_status as `ticket_status`
   FROM tickets_new t, ticket_status s, users u

, users uが問題の原因でした。これを削除することで問題は解決しました。

参考のために、これはCodeIgniter開発環境で行われました。

0
Lee Cocklin

クエリに関係するテーブルのそれぞれに対して修復コマンドを実行してみてください。

MySQL管理者を使用して、カタログ->カタログの選択->テーブルの選択->メンテナンスボタン->修復-> FRMの使用を選択します。

0
MigDus
mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G

その後、エラーが発生しました：

 Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')'

mysql> repair table f_scraper_banner_details;

これは私のために働いた

0
Ashish Karpe