MySQL テーブルはほとんどありません。これらには、約 300 列と 1 億行があります。これらはログファイルのデータを保存するため、サイズが異なります。InnoDB エンジンを使用しています。これらのテーブルの結合を含むいくつかのクエリは、明らかに機能しません。これらにインデックスを追加しようとしましたが、クエリがまったく終了しません。
パフォーマンスを高速化する他の方法があるかどうか、またはテーブルで「インデックスの作成」を機能させる方法があるかどうかを知りたいですか?
ありがとうございました。
インデックスの作成には、テーブル内の行数に比例して時間がかかります。1 億行は、MySQL テーブルにとってかなりの数です。そのテーブルにインデックスを作成するには、おそらく何時間もかかります。正確な時間は、サーバー ハードウェア、インデックスを作成する列のデータ型、データベースのその他の現在の負荷など、他の要因に基づいて異なります。
役立つツールの 1 つがpt-online-schema-changeです。実際にはインデックスの構築に時間がかかりますが、作業中に元のテーブルの読み取りと書き込みを続行できます。小さいテーブルでテストして、このツールの使用経験を積んでください。
このツールに関するウェビナーは、こちらからご覧いただけます: MySQL におけるゼロ ダウンタイム スキーマの変更(閲覧は無料ですが、登録が必要です)。
もう 1 つの手法は、元のような空のテーブルを作成し、そのテーブルにインデックスを作成してから、元のテーブルから新しいテーブルにデータを徐々にコピーし始めることです。これがログ テーブルの場合、テーブルから読み取るよりもテーブルに書き込む方が多い可能性が高いため、テーブルをすぐに交換して新しいイベントのログをすぐに開始し、時間をかけてバックフィルすることができます。
pt-archiverのようなツールは、サーバーに過度の負荷をかけずにデータを段階的にコピーするのに役立ちます。INSERT INTO... SELECT1 回のトランザクションで 1 億行をコピーしようとすると、単純に行うだけではデータベース サーバーの状態が良くありません。また、元のテーブルにロックを設定します。pt-archiver は、一度に一口サイズの行のチャンクのみをコピーすることで機能するため、このような大規模なトランザクションの高コストを回避できます。
自動インクリメントの主キーを使用する場合は、ログ イベントの書き込みを開始する前に、値を元のテーブルの最大値よりも大きくなるように調整して、誤って値を複数回識別しないように注意してください。
使用する
create table newtable like oldtable;
次に、空の間にインデックスを newtable に適用します。
それで
insert into newtable select * from oldtable;
これも、完了するまでに長い時間がかかる場合があります。