60

私は頻繁に助けを求めてここに来ることはありませんが、私はこれにかなり不満を感じており、誰かが以前にそれに遭遇したことを望んでいます。

複数の結合を使用してテーブルからレコードをフェッチしようとすると、次のエラーが発生します。

#126 - Incorrect key file for table '/tmp/#sql_64d_0.MYI'; try to repair it

したがって、このクエリはエラーを生成します。

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

しかし、これはしません：

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

そして、これもそうではありません：

SELECT * FROM `core_username`
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

これを引き起こしている可能性がありますか？tmpテーブルの修復方法はよくわかりませんが、毎回新しいtmpテーブルであるため、それが問題になるとは思いません。ユーザー名テーブルはかなり大きいですが（現在233,718レコード）、それがそれと関係があるとは思えません。

どんな助けでも大歓迎です。

更新：さらにテストした後、結果を注文しようとしたときにのみエラーが発生するようです。つまり、このクエリは私が期待するものを私に与えます：

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
LIMIT 1

しかし、私が追加した場合：

ORDER BY `core_username`.`name` ASC

エラーがトリガーされます。これは、現在使用している特定のWebサーバーでのみ発生します。データベースをダウンロードして、ローカルホストや他のサーバーで同じことを試してみると、正常に動作します。MySQLのバージョンは5.0.77です。

これを知っていると、作成されているtmpテーブルが大きすぎて、このブログ投稿で説明されているようにMySQLがチョークするということが起こっていると私はかなり確信しています。解決策がどうなるかはまだわかりませんが...

4

11 に答える 11

106

一時テーブルでこのエラーが発生する場合があります。

#126 - Incorrect key file for table '/tmp/#sql_64d_0.MYI'; try to repair it

/tmpフォルダの容量が不足している可能性があります。一部の Linux インストールで/tmpは、 は独自のパーティションにあり、多くのスペースがありません - 大きな MySQL クエリがそれをいっぱいにします。

が独自のパーティションにあるdf -hかどうか、およびそれに割り当てられているスペースの量を確認するために使用できます。\tmp

独自のパーティションにあり、スペースが不足している場合は、次のいずれかを実行できます。

(a) /tmp を変更して、そのパーティションがより多くのスペースを持つようにします (メイン パーティションに再割り当てまたは移動することにより - たとえば、ここを参照)
(b) MySql 構成を変更して、別のパーティションで別の一時フォルダを使用するようにします。たとえば、/var/tmp

于 2010-09-15T10:34:03.710 に答える
21

大きなテーブルを操作すると数百MBを消費する可能性があるため、クエリの実行中にMySQL tmpdirの使用可能なスペース（この場合は/ tmp）を確認してください。このようなものが私のために働いた：

$ while true; do df -h /tmp; sleep .5; done
于 2010-03-04T11:01:40.407 に答える
6

これを実行

REPAIR TABLE `core_username`,`core_site`,`core_person`;

またはこれを行います：

select * from (
 SELECT * FROM `core_username`
 INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
 INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
 LIMIT 1)
ORDER BY `name` ASC
于 2010-01-28T13:36:54.337 に答える
2

Unixでは、MySQLはTMPDIR環境変数の値を一時ファイルを保存するディレクトリのパス名として使用します。TMPDIRが設定されていない場合、MySQLはシステムのデフォルト（通常は/ tmp、/ var / tmp、または/ usr / tmp）を使用します。

Windows、Netware、およびOS2では、MySQLはTMPDIR、TEMP、およびTMP環境変数の値を順番にチェックします。最初に設定されたものについては、MySQLはそれを使用し、残っているものをチェックしません。TMPDIR、TEMP、またはTMPのいずれも設定されていない場合、MySQLはWindowsシステムのデフォルト（通常はC：\ windows \ temp）を使用します。

一時ファイルディレクトリを含むファイルシステムが小さすぎる場合は、mysqldの--tmpdirオプションを使用して、十分なスペースがあるファイルシステム内のディレクトリを指定できます。

MySQL 5.0では、-tmpdirオプションを、ラウンドロビン方式で使用されるいくつかのパスのリストに設定できます。パスは、Unixではコロン文字（ "："）で、Windows、NetWare、およびOS / 2ではセミコロン文字（ ";"）で区切る必要があります。

于 2012-03-27T18:22:23.713 に答える
1

同じ問題が発生します。

これが私の解決策です：1.「select *」を使用しないでください。必要なフィールドを選択するだけです。2. クエリを分割します。選択したフィールドが多すぎる場合、それをいくつかのクエリに分割する結果になる可能性があります。結果を含む変数を変更しない場合は、後で結果を「array_merge()」できます。

私の場合、クエリを 5 つのクエリに分割し、PHP を使用して配列をマージします。

問題はmysqlサーバーにあります。それは、アプリケーション開発者 (私たちのような) には特権がないということです。

于 2012-08-09T05:33:27.903 に答える
0

mysqlにはクエリ用のスペースがないため、ファイルtmpのみを増やします...

mount -o remount,size=[NEW MAX SIZE HERE] tmpfs /tmp

リンク参照:

一般エラー: 126 テーブル '/tmp/#sql_254c_0.MYI' のキー ファイルが正しくありません。修復してみてください

[エラー] /usr/sbin/mysqld: テーブル '/mysqltmp/#sql_ca1a_0.MYI' のキー ファイルが正しくありません。修復してみてください

/tmp パーティションのサイズを増やす方法

于 2016-07-08T23:18:05.107 に答える
0

同様の問題がありました。私の場合、所有者/許可が正しくないために問題が発生しました。データ ディレクトリの所有者を mysql ユーザーに変更するだけで、問題は解決しました。

于 2014-09-02T13:27:49.357 に答える
-1

Using the EXPLAIN keyword may help find out how to best optimize this query. Essentially, what you need to do is get the result set as small as possible as quickly as possible. If you have a result set of every row in core_username until the end, when you order it you run the risk of... this.

If you can do the ordering on core_username alone without a problem, you may want to get the min() row as a subquery.

于 2010-01-29T17:42:42.033 に答える
-1

3 つのテーブルの 1 つのインデックス キーが正しくない可能性があります。3 つのテーブルすべてで修復コマンドを実行してみてください。

于 2010-01-28T13:31:25.303 に答える