web-dev-qa-db-ja.com

MySQL、エラー126：テーブルの不正なキーファイル

関連性のある次の質問を読みましたが、返信は私を満足させませんでした： MySQL：＃126-テーブルの不正なキーファイル

問題

クエリを実行すると、このエラーが発生します

エラー126（HY000）：テーブルのキーファイルが正しくありません `

質問

問題を見つけようとしても、見つけられないので、repairコマンドで修正する方法がわかりません。他の方法でこの問題を引き起こしている問題を見つける方法へのポインタはありますか？

クエリ

mysql>       SELECT
    ->         Process.processId,
    ->         Domain.id AS domainId,
    ->         Domain.Host,
    ->         Process.started,
    ->         COUNT(DISTINCT Joppli.id) AS countedObjects,
    ->         COUNT(DISTINCT Page.id)   AS countedPages,
    ->         COUNT(DISTINCT Rule.id)   AS countedRules
    ->       FROM Domain
    ->         JOIN CustomScrapingRule
    ->           AS Rule
    ->           ON Rule.Domain_id = Domain.id
    ->           LEFT JOIN StructuredData_Joppli
    ->             AS Joppli
    ->             ON Joppli.CustomScrapingRule_id = Rule.id
    ->         LEFT JOIN Domain_Page
    ->           AS Page
    ->           ON Page.Domain_id = Domain.id
    ->         LEFT JOIN Domain_Process
    ->           AS Process
    ->           ON Process.Domain_id = Domain.id
    ->       WHERE Rule.CustomScrapingRule_id IS NULL
    ->       GROUP BY Domain.id
    ->       ORDER BY Domain.Host;
ERROR 126 (HY000): Incorrect key file for table '/tmp/#sql_2b5_4.MYI'; try to repair it

mysqlcheck

root@scraper:~# mysqlcheck -p scraper
Enter password: 
scraper.CustomScrapingRule                         OK
scraper.Domain                                     OK
scraper.Domain_Page                                OK
scraper.Domain_Page_Rank                           OK
scraper.Domain_Process                             OK
scraper.Log                                        OK
scraper.StructuredData_Joppli                      OK
scraper.StructuredData_Joppli_Product              OK

カウントされた行

mysql> select count(*) from CustomScrapingRule;
+----------+
| count(*) |
+----------+
|       26 |
+----------+
1 row in set (0.04 sec)

mysql> select count(*) from Domain;
+----------+
| count(*) |
+----------+
|        2 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from Domain_Page;
+----------+
| count(*) |
+----------+
|   134288 |
+----------+
1 row in set (0.17 sec)

mysql> select count(*) from Domain_Page_Rank;
+----------+
| count(*) |
+----------+
|  4671111 |
+----------+
1 row in set (11.69 sec)

mysql> select count(*) from Domain_Process;
+----------+
| count(*) |
+----------+
|        2 |
+----------+
1 row in set (0.02 sec)

mysql> select count(*) from Log;
+----------+
| count(*) |
+----------+
|       41 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from StructuredData_Joppli;
+----------+
| count(*) |
+----------+
|    11433 |
+----------+
1 row in set (0.16 sec)

mysql> select count(*) from StructuredData_Joppli_Product;
+----------+
| count(*) |
+----------+
|   130784 |
+----------+
1 row in set (0.20 sec)

更新

ディスクの使用状況

root@scraper:/tmp# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  4.7G   15G  26% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            237M  4.0K  237M   1% /dev
tmpfs            49M  188K   49M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            245M     0  245M   0% /run/shm
none            100M     0  100M   0% /run/user
mysqlsqlmysql-error-126
28
superhero

クエリが一時テーブルの作成を必要とする大きな中間結果セットを返し、mysql一時ディスクテーブル（/ tmp）の構成場所が結果の一時テーブルに対して十分な大きさではないようです。

再マウントしてtmpfsパーティションサイズを増やしてみてください：

mount -t tmpfs -o remount,size=1G tmpfs /tmp

/ etc/fstabを編集して、この変更を永続的にすることができます

これができない場合は、my.cnfファイルの「tmpdir」エントリを編集して、ディスクの一時テーブルの場所を変更してみてください（まだない場合は追加してください）。選択したディレクトリはmysqlユーザーが書き込み可能である必要があることに注意してください

Mysql構成オプションの値を増やして、ディスク上の一時テーブルの作成を防止することもできます。

tmp_table_size
max_heap_table_size

より大きな値に。上記の両方のパラメーターを増やす必要があります

例：

set global tmp_table_size = 1G;
set global max_heap_table_size = 1G;
40
Cillier

私の場合、一時的な場所から一時ファイルを消去するだけです：

my.ini

tmpdir = "D：/ xampp/tmp"

そしてそれは私のために働いた。

1
SA Soibal

複雑なクエリを複数のクエリに分割すると、一時テーブルのサイズを増やす必要がなくなり、より高速になります。

1
John

Linuxファイルシステム上の/tmpマウントがオーバーフローとしてマウントされ、多くの場合1MBのサイズの場合

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.9G   12K  7.9G   1% /dev
tmpfs           1.6G  348K  1.6G   1% /run
/dev/xvda1      493G  6.9G  466G   2% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            7.9G     0  7.9G   0% /run/shm
none            100M     0  100M   0% /run/user
overflow        1.0M  4.0K 1020K   1% /tmp               <------

これはおそらく、/tmpを独自のパーティションとして指定せず、ルートファイルシステムがいっぱいになり、/tmpがフォールバックとして再マウントされたためです。

EC2ボリュームのスペースが不足した後、この問題に遭遇しました。ボリュームのサイズを変更すると、複雑なビューの実行中に/tmpオーバーフローパーティションがいっぱいになりました。

Sudo umount -l /tmp

注：-lは、ディスクを遅延してアンマウントします。

1
Carrie Kendall