ディスク I/O を最小化するために、MyISAM ストレージエンジンは多数のデータベースマネージメントシステムで使用される戦略を利用します。メモリー内でもっとも頻繁にアクセスされるテーブルブロックを保持するために、キャッシュメカニズムが使用されます。

この節では最初に MyISAM キーキャッシュの基本的な演算について説明しています。キーキャッシュパフォーマンスを向上させる特徴や、キャッシュオペレーションをよりよくコントロールできる特徴について、説明されています。

キーキャッシュのサイズを制限するには、key_buffer_size システム変数を使用します。この変数がゼロに設定された場合、利用できるキーキャッシュはありません。key_buffer_size 値が小さすぎてブロックバッファーの最小値が割り当てられない場合、キーキャッシュも使用できません (8)。

キーキャッシュが作動していない場合、インデックスファイルはオペレーティングシステムによるネイティブファイルシステムバッファリングのみ使用してアクセスされます。(つまり、テーブルインデックスブロックはテーブルデータブロック利用と同様の方法でアクセスされる。)

インデックスブロックは MyISAM インデックスファイルにアクセスする隣接ユニットです。通常、インデックスブロックのサイズは、インデックス B-tree のノードサイズと等価です。(インデックスは B-tree データ構造を使用してディスク上で表現されます。ツリーの元にあるノードはリーフノードです。リーフノードの上層にあるノードは非リーフノードです。)

キーキャッシュ構造内のブロックバッファーはすべて同サイズです。このサイズは、テーブルインデックスブロックサイズと比べて、等しい/大きい/小さい場合があります。通常これら 2 つの値のうち一方は、他方の複合となっています。

あるテーブルインデックスブロックのデータアクセスが必要な場合、サーバーはまずキーキャッシュのどれかのブロックバッファー内で利用可能かどうかをまず確認します。可能である場合、サーバーはディスク上ではなく、キーキャッシュのデータにアクセスします。つまり、ディスクからではなく、キャッシュから読むかまたはキャッシュに書きこみます。でなければ、異なるテーブルインデックスブロックを含むキャッシュブロックバッファーを選択し、そのデータを要求されたテーブルインデックスブロックのコピーと置き換えます。新しいインデックスブロックがキャッシュ内におかれるとすぐ、インデックスデータはアクセス可能となります。

置き換えのために選択されたブロックが変更されていた場合、ブロックは「汚染されている」と見なされます。「」この場合、置き換えられる前に、内容は元のテーブルインデックスにフラッシュされます。

通常サーバーはLRU (Least Recently Used)戦略に従います。置換のためブロックを選択した場合、最近使用した中でもっとも初期に使用されたインデックスブロックを選択します。この選択を簡単にするために、キーキャッシュモジュールは、使用されたすべてのブロックの特別なキュー (LRU chain) を保持します。ブロックがアクセスされた場合、キューの最後尾に置かれます。ブロックを置換する必要がある場合、キューの最前部にあるブロックは、最近使用した中でもっとも初期に使用されたものであり、かつ最初の除去対象となります。