MySQLのインデックスのステータスを決定します

Question

3500万レコードを含むテーブルに新しいインデックスを作成しましたが、1日近く実行されています。以前はインデックスを作成したとき、20分かかりましたが、列はフロートでした。新しいIDNEXはVARCHAR（45）にあります

インデックス作成がまだ次の出力で進行中であることを示すプロセスリストコマンドを使用しました

65417 | Repair with keycache | CREATE INDEX insert_index on checkins(dateinserted)

クエリが実際に死んでいて、プロセスリストに座っているかどうかを知ることについて、誰かが私にアドバイスをすることができるかどうか疑問に思っていました。ある段階で何かが間違っているのかもしれませんが、私は気づいていません。

ありがとう

Answer 1

インデックスは構築されていますが、非常にゆっくりです。

MySQLには、インデックスの構築に使用できる2つの方法があります。

1. 並べ替えによって。これは最速の方法ですが、多くのメモリを使用します。
2. keycacheによって。遅い、遅い、遅い - しかし、ほとんどメモリを使い果たします。

keycacheメソッドは、挿入ソートに少し似ています。値は、一度に1つずつインデックスに挿入されます。これは、挿入ステートメントがテーブルに行を追加するために使用される場合にサーバーが使用する同じ方法です。

ソートメソッドは、QuickSortを使用してすべての値をソートし、それからインデックスを構築します。非常に高速ですが、多くのメモリと一時的なディスクスペースが必要です。

一部のサーバー変数は、ソートメソッドで利用可能なスペースを増やすことができるため、大きなテーブルで動作させることができます。 myisam_max_sort_file_sizeを参照してください

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_myisam_max_sort_file_size

Linuxでは、インデックスの構築に使用される一時ファイルのサイズをチェックすることにより、インデックス修理の進捗を追跡できます。次のコマンドには、MySQLプロセスによって開いているすべてのファイルがリストされます。

sudo ls -l /proc/[mysql-pid]/fd  

次に、名前にハッシュが付いたサイズのサイズをチェックしてください - これらは一時ファイルです。

Answer 2

インデックスサイズは少なくとも35m*45になることに注意してください。 UTF8列の場合、35m*45*3になります。それは4つ以上のギグです！ RAMが大量のRAMを持っていない場合は、多くのディスクアクセスを行い、実際にパフォーマンスを殺す必要があることをサポートします。

この列を別のテーブルに正規化できますか？

そうでない場合は、最初の8文字と言った場合、値は十分に変化する傾向がありますか？最初の8をインデックス化するだけで逃げることができるかもしれません。