5

3,500 万件のレコードを含むテーブルに新しいインデックスを作成し、現在 1 日近く実行しています。以前はインデックスを作成するのに 20 分かかりましたが、列が浮動していました。新しい idnex は varchar(45) にあります

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

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

クエリが実際に死んでいて、プロセスリストに座っているだけかどうかを調べるためのアドバイスを誰かに教えてもらえないかと思っていました。ある段階で何かがうまくいかなかったのかもしれませんが、私は気づいていません。

ありがとう

4

2 に答える 2

7

インデックスは作成中ですが、非常にゆっくりです。

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

  1. 並べ替えによって。これは最速の方法ですが、多くのメモリを消費します。
  2. キーキャッシュによる。遅い、遅い、遅い-しかし、メモリをほとんど消費しません。

キーキャッシュ方式は挿入ソートに少し似ています。値は一度に1つずつインデックスに挿入されます。これは、INSERTステートメントを使用してテーブルに行を追加するときにサーバーが使用するのと同じメソッドです。

並べ替え方法では、クイックソートを使用してすべての値を並べ替え、そこからインデックスを作成します。非常に高速ですが、大量のメモリと一時ディスク領域が必要です。

一部のサーバー変数は、並べ替え方法で使用できるスペースを増やすことができるため、より大きなテーブルで機能することができます。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  

次に、名前にハッシュが含まれているもののサイズを確認します。これらは一時ファイルです。

于 2010-10-03T16:38:55.633 に答える
2

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

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

そうでない場合、値は最初の 8 文字で十分に変化する傾向がありますか? 最初の 8 つのインデックスを作成するだけで済む場合があります。

于 2010-10-03T17:50:00.823 に答える