現在、MyISAM テーブルに対していくつかの集中的な SELECT クエリを実行しています。テーブルは約 100 MiB (800,000 行) で、変更されることはありません。
スクリプトのパフォーマンスを向上させる必要があるため、テーブルを MyISAM から MEMORY ストレージ エンジンに移動して、完全にメモリにロードできるようにすることを考えていました。
MEMORY ストレージ エンジン以外に、100 MiB テーブルをメモリにロードするためのオプションは何ですか?
現在、MyISAM テーブルに対していくつかの集中的な SELECT クエリを実行しています。テーブルは約 100 MiB (800,000 行) で、変更されることはありません。
スクリプトのパフォーマンスを向上させる必要があるため、テーブルを MyISAM から MEMORY ストレージ エンジンに移動して、完全にメモリにロードできるようにすることを考えていました。
MEMORY ストレージ エンジン以外に、100 MiB テーブルをメモリにロードするためのオプションは何ですか?
データがめったに変更されないと仮定すると、 MySql クエリ キャッシングを使用して、クエリのパフォーマンスを大幅に向上させることができる可能性があります。
テーブルが頻繁にクエリされる場合、サーバーのメモリ量によっては、オペレーティング システム レベルで既にキャッシュされている可能性があります。
MyISAM では、 MyISAM キー キャッシュと呼ばれるメカニズムを使用して、MyISAM テーブル インデックスをメモリにプリロードすることもできます。キー キャッシュを作成したら、CACHE INDEXまたはLOAD INDEX構文を使用してインデックスをキャッシュにロードできます。
テーブルとクエリを分析し、実際のクエリの後にインデックスを最適化したと思いますか? それ以外の場合は、テーブル全体をメモリに格納する前に、実際に行う必要があります。
Innodb バッファー プールで、または MyIsam で使用するために、Mysql の使用に十分なメモリが割り当てられている場合は、データベースをメモリに読み込むことができ (単に 'SELECT * from tablename')、それを削除する理由がない場合はそのままにします。そこの。
MEMORY テーブルは完全な btree アクセスではなく、ハッシュ化されたキーのみを実行するため、キーの使用も向上します。これは、小さくて一意でないキーの場合、十分に太いか、そのような大きなテーブルではそれほど太くない可能性があります。
いつものように、それをベンチマークするのが最善の方法です。
もう 1 つのアイデアは、v5.1 を使用している場合、圧縮可能な ARCHIVE テーブル タイプを使用することです。簡単に圧縮できる場合は、コンテンツへのアクセスも高速化できます。これにより、CPU 時間がスワップされて、IO/メモリ アクセスの解凍が行われます。
データがまったく変更されない場合は、複数のデータベース サーバーにテーブルを簡単に複製できます。
このようにして、一部のクエリを別のサーバーにオフロードし、メイン サーバーに余裕を持たせることができます。
速度の向上は、現在のデータベースの負荷によって異なります。データベースの負荷が非常に低い場合、速度は向上しません。
PS:
データベースが再起動すると、MEMORY テーブルの内容が失われることに注意してください。