私たちは非常に大きなデータベースを持っており、避けたいシャードを使用しています。シャードは、テーブルが非常に大きくなるたびに機能します。前のテーブルと同じスキーマを持つ新しいテーブルを開始し、データがどのテーブルにあるかを見つけるのに役立つ別のテーブルに番号を保持します。これは面倒な手動プロセスであり、これは、すべて同じスキーマを持つ N 個の異なるテーブルにデータが分散していることを意味します。
私たちが目指しているのは、インデックスを使用してシャーディングの必要性を排除することです。データ ルックアップ クエリは一意のキーを使用せず、列全体で同じ値を持つ多くのレコードが返されます。
以下は、特定のテーブルのルックアップ選択の多くを示しています。* の付いたフィールドは、そのフィールドが選択にある場合とない場合があることを示しています。
where句：scheduled_test、*script、*label、*error_message
グループ/オーダー:messenger_id、timeslice、script、label、error_message、step_sequence、*adapter_type
私の考えでは、これら 11 個のフィールドすべてを含むインデックスを作成したくはありません。代わりに、常に where 句にあるものを含め、より一般的に使用されていると思われるものを 3 つ選びました。フィールドが多すぎるインデックスを使用しないことをお勧めします。また、オプティマイザーは最初にインデックス付きフィールドを使用し、MSDN は一意のインデックスが大きな利点であると述べていますが、一意でないインデックスを持つことは珍しくないと聞いていました。それは、私たちのデータがどのように設計されているかだけではありません。SQL がインデックスに何かを追加して一意にすることは理解していますが、それは私たちの目的には関係ないようです。
実行する可能性のあるクエリに似たクエリでSQL Server Management Studioの実行計画を見ると、「クラスター化インデックスのシークコスト100％」と表示されますが、作成したクラスター化インデックスを使用しているので、これを望んでいます生成された主キーのみであるデフォルトのクラスター化インデックスよりも優れています (以前のテーブルの定義方法)。私がここに持っているものが、私たちのシャーディング方法と同じかそれ以上のものであり、シャードの必要性を排除することを願っています.
一度に大量のデータをテーブルに挿入しますが、これらの行はすべて多くの列で同じデータ値を持ち、最後にも挿入される傾向があると思います. これらの挿入は古いデータと値を共有しません。インデックスが 3 列だけの場合、挿入で大きなヒットにならないことを願っています。
私が言っていることは合理的ですか、それとも他に何を調べたり検討したりする必要がありますか? どうもありがとう、私はこれらのタイプのインデックス作成の問題に精通していませんが、さまざまなWebサイトを調べて実験してきました.