テーブルの分割によりクエリが高速化されますか？
私のデータベースは、ステージングテーブルとライブテーブルと呼ばれるものでセットアップされています。現在、productsというテーブルに約200万行あります。メーカーと呼ぶお客様は、データをステージングテーブルにロードし、データの更新、追加、削除が完了すると、そのデータをライブテーブルにプッシュします。
これらのライブテーブルは、モバイルアプリとWebサイトのWebサービスにフィードします。ステージングからライブへのデータのプッシュは、ライブテーブル内のすべてのデータを削除し、ステージングテーブルからすべてのデータを挿入することで構成されます。これらはすべて、すべてのテーブルに存在するManufacturerIDという列によって分離されています。
500の製品を提供しているメーカーもあれば、75,000を提供しているメーカーもあります。これによっては、200万件のレコードすべてをページングするため、Webサービスの応答が非常に遅くなることがあります。ライブテーブルからのデータの削除も、途方もなく遅くなっているようです。
製品テーブルをManufacturerIDでパーティション化すると、この状況に役立ちますか？私が読んだことから、これは基本的に自分の製品をクエリしているとき、そのManufacturerID上のデータベースの小さなサブセットのみをクエリしているため、全体的な応答時間が大幅に改善されることを意味します。
いいえ。パーティショニングはスピードアップしません。パーティション化する前に200万のレコードがあるテーブルでは、パーティション化後もまったく同じ200万のレコードが残ります。レコードの小さなサブセットのみを見たい場合は、indexを使用します。データはマルチテナントスキーマのようで、テナントキーはManufacturerIDです。このような場合、最も可能性の高い設計は、ManufacturerIDをクラスター化インデックスの主要なキーにすることです。ところで、私は Multi-Tenant Data Architecture を読むことをお勧めします。
パーティショニングは、高速のデータスイッチインとスイッチアウトを伴うシナリオ、またはデータの分散が異なる物理パス（ファイルグループ）を必要とするシナリオで役立ちます。よく読んでください テーブルパーティションを使用する必要があるかどうかを判断する方法 。
「 パーティションの削除 についてはどうですか？」私はこれを言います：パーティションの削除がインデックスがより良くできないことができることはほとんど何もありません。言うまでもなく、クラスター化されたインデックスの先頭のキーの範囲スキャンは、ほとんどの場合、パーティションの削除は宝くじです。さらに、パーティションごとにテナントはいくつありますか？そして、それらをどのように均等に分配しますか？これらの問題はどちらも、クラスタ化インデックスの主要なキーによって大幅に改善されます。そして、特に、巨大な設計変更がパーティション分割をもたらすことを考慮してください（たとえば、一意/主キー制約に別れを告げるか、アラインされていないインデックスを導入する） パーティションインデックスの特別なガイドライン） 、「メモリの制限」セクションに特に注意してください。
パーティショニングは素晴らしい機能ですが、パフォーマンス機能ではありません。パーティショニングの助けになる例は、ステージングされたデータの非常に高速なスイッチインを実行することです（これは発生した問題です）が、メーカーごとに1つのパーティションであり、各「メーカー」がビジネスのクライアント（テナント）であると仮定すると、スケーリングされません。