効率的に分割したい大きなテーブル（数億行）があります。私の質問は、パーティションサイズとパーティション数の間にトレードオフがあるかどうかです。私が理解している限り、クエリは（ほとんどのクエリに対して）クエリに適用可能なパーティション内のみを検索する必要があるため、パーティションで使用される列に対するほとんどのクエリはより高速になります。したがって、効率を最大化するには、大きなテーブルを最大数のパーティションに分割する必要があるので、各パーティションをできるだけ小さくする必要があります。MySQLの場合、これは1024パーティションを意味します。しかし、多数のパーティションを持つことにはパフォーマンス上の欠点がありますか？そうであれば、どのようにして最適なパーティション数を見つけるのでしょうか？
注：stackoverflowについては多少似た質問がすでにありますが、（私の観点から）マークを逃す答えは1つだけです。だから私は私自身の方法で質問を述べます...うまくいけばそれはより明確です
回答:
それらを比較してみましょう
次のものがある場合：
メトリックはどのように見えますか？
LOG（100000000）/ LOG（2）= 26.575424759099なので、ページツリーノードあたり1024キーのBTREEインデックスは、ツリーの高さが3（CEILING（LOG（100000000）/ LOG（1024）））しかありません。3ページのみのノードの場合、アクセスされた各ツリーノードで必要なキーをバイナリ検索すると、約30個のキーが剪定および分離されます。
次のものがある場合：
数値は少し異なります。
各パーティションには約97656行が必要です。メトリックは今どのようになりますか？
LOG（97656）/ LOG（2）= 16.575421065795なので、ページツリーノードあたり1024キーのBTREEインデックスは、ツリーの高さが2（CEILING（LOG（97656）/ LOG（1024）））しかありません。2ページのみのノードの場合、アクセスされた各ツリーノードで必要なキーをバイナリ検索すると、約20個のキーが剪定および分離されます。
キーを分散すると、1つのツリーレベルが削除されるだけですが、基本的には1024のインデックスが作成されます。クエリは違いを知りません。検索時間は、パーティションを優先して、せいぜい名目上です。ただし、すべてのデータがアクティブであることを確認してください。それ以外の場合、ごく少数のパーティションにヒットする可能性がありますが、ほとんどアクセスされないデータを持つ他のパーティションは領域を占有するだけで、パーティション分割を正当化するほど頻繁にアクセスされることはありません。より露骨なことを心配するために、さまざまなパフォーマンスメトリックがある場合があります（XFSの内部デフラグ、ext3とext4など）。また、次の理由により、使用しているストレージエンジンについても考慮する必要があります。