ほとんどの場合、ディスクシークをカウントしてパフォーマンスを推定できます。小さいテーブルの場合は一般に 1 つのディスクシークでレコードを検索できます (インデックスがキャッシュされることが多いため)。大きいテーブルの場合の推定では、(B ツリーインデックスを使用して) log(row_count) / log(index_block_length / 3 × 2 / (index_length + data_pointer_length)) + 1 のシークがレコードの検索に必要になります。

MySQL では、インデックスブロックが通常 1,024 バイトで、データポインタは通常 4 バイトです。キー値の長さが 3 バイト (MEDIUMINT) の 500,000 レコードのテーブルの場合は次のようになります。log(500,000)/log(1024/3×2/(3+4)) + 1 = 4 シーク

上のインデックスでは約 500,000 × 7 × 3/2 = 5.2MB が必要になるため (一般的な状況としてインデックスバッファーの 2/3 が使用されていると想定)、メモリーにインデックスの多くがあり、OS からデータを読み取り、レコードを検索するには、1 回か 2 回の呼び出しで済むと推定されます。

ただし、書き込みについては、上記の例で新規インデックスの配置場所を探し出すのに 4 シークの要求が、また、インデックスの更新とレコードの書き込みに通常 2 シークが必要になります。

Note that このことは、アプリケーションが対数 N の分だけ低速になるという意味ではないことに注意してください。OS または SQL サーバーですべてがキャッシュされているかぎり、テーブルが拡大しても速度の低下はわずかです。データがキャッシュできないほど増加すると、ディスクシーク (対数 NN の分だけ増加する) によって最終的にアプリケーションがバインドされるまで大幅に速度の低下が始まります。これを回避するには、データの増加に合わせてインデックスキャッシュも拡大します。MyISAM テーブルに関しては、キーキャッシュサイズは key_buffer_size システム変数に制御されます。項4.5.3. 「サーバーパラメータのチューニング」 を参照してください。