キーキャッシュへの共有アクセスはパフォーマンスを向上させますが、スレッド間の競合を完全には削除しません。キーキャッシュバッファへアクセスするためのコントロール構造をめぐって競合が行われます。キーキャッシュアクセス競合をさらに軽減するために、MySQLは複合キーキャッシュも提供しています。この特性によって、異なるキーキャッシュに対して各テーブルインデックスの割り当てが可能となります。
複合キーキャッシュがある場合、サーバは既存のMyISAM
テーブルに対してクエリ処理を行う際に、どのキャッシュを使用すべきか知らされていなければなりません。デフォルトでは、全てのMyISAM
テーブルインデックスはデフォルトキーキャッシュ内にキャッシュされます。テーブルインデックスを特定のキーキャッシュに割り当てるには、CACHE
INDEX
ステートメントを使用してください。(項12.5.5.1. 「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
はキャッシュ部位です。構造キーキャッシュシステム変数に対して使用される構文の詳細については、項4.2.4.1. 「構造化システム変数」を参照してください。
デフォルトではテーブルインデックスは、サーバ起動時に、メイン(デフォルト)キーキャッシュに割り当てられます。.キーキャッシュが破壊された場合、それに割り当てられた全てのインデックスはデフォルトキーキャッシュに再度割り当てられます。
サーバが込んでいる場合、以下の3つのキーキャッシュを使用する戦略をお勧めします。
全てのキーキャッシュに割り当てられたスペースの20%以上を占める「hot」キーキャッシュ。 検索に使用される頻度が高く、かつ更新されていないテーブルに対してはこれを使用してください。
全てのキーキャッシュに割り当てられたスペースの20%以上を占める「cold」キーキャッシュ。 このキャッシュは、テンポラリテーブルのような中位の集中的に改良されたテーブルに使用してください。
キーキャッシュスペースの60%以上を占める「warm」キーキャッシュ。これをデフォルトで全ての他のテーブルに使用されるように、このキーキャッシュをデフォルト設定してください。
上記3つのキーキャッシュを使用する理由のひとつの利点は、1つのキーキャッシュ構造は他二つのキーキャッシュへのアクセスを阻害しない点です。あるキャッシュに割り当てられたテーブルにアクセスするステートメントは、他のキャッシュに割り当てられたテーブルにアクセスするステートメントとは競合しいません。.パフォーマンス向上には他の理由もあります。
hotキャッシュはクエリの取得にのみ使用されるため、内容は決して改良されません。結果、インデックスブロックがディスクから引き抜かれなければならない場合でも、置換のために選択されたキャッシュブロック内容は最初にフラッシュされる必要はありません。
キャッシュに割り当てられたインデックスにとって、インデックススキャンを必要とするクエリがなければ、インデックスB-treeの非リーフノードに一致するインデックスブロックがキャッシュに残っている可能性が高くなります。
テンポラリテーブルに対する最も頻度が高い更新オペレーションは、更新ノードがキャッシュ内にあり、最初にディスクから読まれる必要がない場合、処理速度がはるかに向上します。テンポラリテーブルのインデックスサイズが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
MySQL Enterprise.
my.cnf/my.ini
オプションファイルに対する最適なコンフィギャを行う際のアドバイスを得るには、MySQL
Network Monitoring and Advisory
Serviceを購読してください。実際のテーブル使用量に基づいて行うことをお勧めします。追加情報については
http://www-jp.mysql.com/products/enterprise/advisors.htmlを参照してください。
サーバが再起動するたびに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