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

このセクションではまず MyISAM キーキャッシュの基本動作について説明します。 次に、キーキャッシュパフォーマンスを向上させる機能と、キャッシュ操作をより適切に制御できるようにする機能について説明します。

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

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

インデックスブロックは MyISAM インデックスファイルへの連続したアクセスの単位です。 通常、インデックスブロックのサイズは、インデックス B ツリーのノードのサイズと等しくなります。 (インデックスはディスク上で B ツリーデータ構造を使用して表されます。 ツリーの下部にあるノードはリーフノードです。 リーフノードの上にあるノードは非リーフノードです。)

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

いずれかのテーブルインデックスブロックのデータにアクセスする必要がある場合、サーバーはまず、キーキャッシュの何らかのブロックバッファーでそれを使用できるかどうかを確認します。 そうである場合、サーバーはディスク上ではなく、キーキャッシュ内のデータにアクセスします。 つまり、ディスクから読み取ったり、それに書き込んだりするのではなく、キャッシュから読み取ったり、それに書き込んだりします。 そうでない場合、サーバーは別のテーブルインデックスブロックを含むキャッシュブロックバッファーを選択し、そのデータを必要なテーブルインデックスブロックのコピーで置き換えます。 新しいインデックスブロックがキャッシュに入れられるとただちに、インデックスデータにアクセスできます。

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

通常サーバーは LRU (Least Recently Used) 戦略に従います。置き換えるブロックを選択する場合、直近で使用されていないインデックスブロックを選択します。 この選択を簡単にするため、キーキャッシュモジュールは、使用されたすべてのブロックを特別なリスト (LRU チェーン) に使用時間で順序付けして保持しています。 ブロックがアクセスされると、それは直近で使用されたものになり、リストの末尾に置かれます。 ブロックを置き換える必要がある場合、リストの先頭にあるブロックが、直近で使用されていないことになり、エビクションの最初の候補になります。

InnoDB ストレージエンジンは、そのバッファープールを管理するためにも LRU アルゴリズムを使用します。 セクション15.5.1「バッファプール」を参照してください。