MySQL 5.6 リファレンスマニュアル  /  ...  /  クエリーパフォーマンスの推定

8.8.4 クエリーパフォーマンスの推定

ほとんどの場合、ディスクシークをカウントしてクエリーパフォーマンスを推定できます。小さいテーブルの場合は一般に 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 回のシークが必要になります。

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


User Comments
Sign Up Login You must be logged in to post a comment.