シナリオ1000万行のテーブルがあります。10個のパーティションに分割します。これにより、パーティションあたり100万行になりますが、他には何もしません（パーティションを別のファイルグループやスピンドルに移動するなど）。
パフォーマンスは向上しますか？これは実際には、10個の小さなテーブルを作成するようなものですか？キールックアップまたはスキャンを実行するクエリがある場合、はるかに小さなテーブルに対して動作しているかのようにパフォーマンスが向上しますか？
パーティション化が、適切にインデックス付けされたテーブルを持つこととどのように異なるのか、そしてパフォーマンスを向上させるためにどこで使用できるのかを理解しようとしています。
古いデータ（パーティションの切り替えを使用）をプライマリテーブルから読み取り専用のアーカイブテーブルに移動するのがより良いシナリオでしょうか？
100万行のパーティションと900万行のパーティションを持つテーブルが（パフォーマンス的に）類似していて、900万行を別のテーブルに移動し、元のテーブルに100万行しか残していませんか？
パーティショニングはパフォーマンス機能ではなく、テーブル間でのデータの移動やデータのドロップなどのメンテナンス操作のためのものです。10M行のテーブルを100万行の10パーティションに分割すると、ほとんどのクエリのパフォーマンスが向上しないだけでなく、かなりの数のクエリの 速度が低下する可能性があります。
単一のパーティション内の行のみが必要であるとクエリが判断できない限り、単一のパーティションのより小さな行セットに対してクエリを実行することはできません。しかし、これは、テーブル上のクラスター化されたインデックスを適切に選択するか、少なくとも非クラスター化インデックスを適切にカバーすることによって、常に、そしてはるかにうまく解決できます。
最初のパーティショニングは、エンタープライズバージョンを使用している場合にのみ役立ちます。実際のメリットは特定の作業負荷によって異なりますが、パフォーマンスが向上すると思います（ええ、常に異なります）。
10個の小さなテーブルを作成するのとまったく同じではありませんが、クエリがパーティションの範囲に対して実行される場合、そのパーティションのデータは「タッチ」するだけです。そのような場合、パフォーマンスの向上が顕著になると思います。クエリがパーティション範囲全体で実行される場合、パフォーマンスは低下します。
データに最適なソリューションを試す必要があると思います。パーティションが役立つ場合もあれば、逆の場合もあります。パーティション化のもう1つの利点は、データの移動について心配する必要がないことです。その周り。
これはパーティション分割についての良い記事です-bol