Skip navigation links
4.4.5.3 ミッドポイント挿入戦略 »
Section Navigation      [Toggle]

4.4.5.2. 複合キーキャッシュ

キーキャッシュへの共有アクセスはパフォーマンスを向上させますが、セッション間の競合を完全には排除しません。キーキャッシュバッファーへアクセスするためのコントロール構造をめぐって競合が行われます。キーキャッシュアクセス競合をさらに軽減するために、MySQL は複合キーキャッシュも提供しています。この特性によって、異なるキーキャッシュに対して各テーブルインデックスの割り当てが可能となります。

複合キーキャッシュがある場合、サーバーは既存の MyISAM テーブルに対してクエリー処理を行う際に、どのキャッシュを使用すべきか知らされていなければなりません。デフォルトでは、すべての MyISAM テーブルインデックスはデフォルトキーキャッシュ内にキャッシュされます。テーブルインデックスを特定のキーキャッシュに割り当てるには、CACHE INDEX ステートメントを使用してください (項8.5.6.2. 「CACHE INDEX 構文」を参照してください)。たとえば、次のステートメントは t1、t2、そして t3 テーブルから、hot_cache と名づけられたキーキャッシュにインデックスを割り当てます。 

mysql> CACHE INDEX t1, t2, t3 IN hot_cache;
+---------+--------------------+----------+----------+
| Table   | Op                 | Msg_type | Msg_text |
+---------+--------------------+----------+----------+
| test.t1 | assign_to_keycache | status   | OK       |
| test.t2 | assign_to_keycache | status   | OK       |
| test.t3 | assign_to_keycache | status   | OK       |
+---------+--------------------+----------+----------+

CACHE INDEX ステートメント内の参照キーキャッシュは、SET GLOBAL パラメータ設定ステートメントを用いてサイズを設定するか、またはサーバースタートアップオプションを使用して作成できます。例 : 

mysql> SET GLOBAL keycache1.key_buffer_size=128*1024;

キーキャッシュを破壊するにはサイズをゼロに設定してください。 

mysql> SET GLOBAL keycache1.key_buffer_size=0;

デフォルトキーキャッシュを破壊することはできない点に注意してください。この破壊に関してはいずれの試みも無視されます。 

mysql> SET GLOBAL key_buffer_size = 0;
mysql> SHOW VARIABLES LIKE 'key_buffer_size';
+-----------------+---------+
| Variable_name   | Value   |
+-----------------+---------+
| key_buffer_size | 8384512 |
+-----------------+---------+

キーキャッシュ変数は名前と部位のある構造システム変数です。keycache1.key_buffer_size にとって、keycache1 はキャッシュ変数名であり、key_buffer_size はキャッシュ部位です。構造キーキャッシュシステム変数に対して使用される構文の詳細については、Structured System Variablesを参照してください。

デフォルトではテーブルインデックスは、サーバー起動時に、メイン (デフォルト) キーキャッシュに割り当てられます。キーキャッシュが破壊された場合、それに割り当てられたすべてのインデックスはデフォルトキーキャッシュに再度割り当てられます。

サーバーが混んでいる場合、次の 3 つのキーキャッシュを使用する戦略をお勧めします。

  • すべてのキーキャッシュに割り当てられたスペースの 20%以上を占める「hot」キーキャッシュ。検索に使用される頻度が高く、かつ更新されていないテーブルに対してはこれを使用してください。

  • すべてのキーキャッシュに割り当てられたスペースの 20%以上を占める「cold」キーキャッシュ。このキャッシュは、一時テーブルのような中位の集中的に改良されたテーブルに使用してください。

  • キーキャッシュスペースの 60%以上を占める「warm」キーキャッシュ。これをデフォルトですべてのほかのテーブルに使用されるように、このキーキャッシュをデフォルト設定してください。

上記 3 つのキーキャッシュを使用する理由のひとつの利点は、1 つのキーキャッシュ構造は他二つのキーキャッシュへのアクセスを阻害しない点です。あるキャッシュに割り当てられたテーブルにアクセスするステートメントは、ほかのキャッシュに割り当てられたテーブルにアクセスするステートメントとは競合しいません。パフォーマンス向上にはほかの理由もあります。

  • hot キャッシュはクエリーの取得にのみ使用されるため、内容は決して改良されません。結果、インデックスブロックがディスクから引き抜かれなければならない場合でも、置換のために選択されたキャッシュブロック内容は最初にフラッシュされる必要はありません。

  • hot キャッシュに割り当てられたインデックスの場合、インデックススキャンを必要とするクエリーがなければ、インデックス B ツリーの非リーフノードに一致するインデックスブロックがキャッシュに残っている可能性が高くなります。

  • 一時テーブルに対するもっとも頻度が高い更新オペレーションは、更新ノードがキャッシュ内にあり、最初にディスクから読まれる必要がない場合、処理速度がはるかに向上します。一時テーブルのインデックスサイズが cold キーキャッシュのサイズと同等の場合、更新ノードがキャッシュ内にある可能性が高くなります。

CACHE INDEX はテーブルとキーキャッシュの関連性を設けますが、サーバーが再起動するたびにその関連性は失われます。サーバーが再起動するたびに関連性を有効にしたい場合、オプションファイルを使用することで実行できます。キーキャッシュをコンフィギャする変数設定と、CACHE INDEX ステートメントを実行するファイルに名前をつける init-file オプションを含んでください。例 : 

key_buffer_size = 4G
hot_cache.key_buffer_size = 2G
cold_cache.key_buffer_size = 2G
init_file=/path/to/data-directory/mysqld_init.sql

サーバーが再起動するたびに mysqld_init.sql でのステートメントは実行されている。ファイルはラインごとの 1 つの sql のステートメントを含むべきである。次の例は hot_cache と cold_cache に複数のテーブルをそれぞれ割り当てる。 

CACHE INDEX db1.t1, db1.t2, db2.t3 IN hot_cache
CACHE INDEX db1.t4, db2.t5, db2.t6 IN cold_cache