ほとんどの場合、ディスクシークをカウントしてクエリーパフォーマンスを推定できます。 小さいテーブルの場合は一般に 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.2M バイト (2/3 の一般的なインデックスバッファー充てん率と想定して) のストレージが必要であるため、インデックスの多くをメモリーに置く可能性が高く、データを読み取り、行を見つけるために 1 つか 2 つの呼び出しだけで済みます。

ただし、書き込みについては、新しいインデックス値の配置場所を見つけるために 4 つのシークリクエスト、およびインデックスの更新と行の書き込みに通常 2 回のシークが必要になります。

前述の説明は、アプリケーションのパフォーマンスがログ N によってゆっくりと低下することを意味しません。 OS または MySQL サーバーによってすべてがキャッシュされているかぎり、テーブルが大きくなってもほんの少し遅くなるだけです。 データがキャッシュできないほど大きくなると、アプリケーションがディスクシーク (これは log NN ずつ増加する) によってのみ制限されるまで著しく遅くなり始めます。 これを回避するには、データの増加に合わせてキーキャッシュを増やします。 MyISAM テーブルでは、キーキャッシュサイズは key_buffer_size システム変数によって制御されます。 セクション5.1.1「サーバーの構成」を参照してください。