sql-server - クラスター化インデックスの主キーを含む非クラスター化インデックスを持つことは悪いことですか?

Question

主キー (int) にクラスター化インデックスを持つテーブルがある場合、非クラスター化インデックスの列の 1 つとしてその主キー列を含む 1 つ (または複数) の非クラスター化インデックスを持つことは冗長であり、悪いことですか? ?

Answer 1

実際には、クラスター化されたものと同一の非クラスター化インデックスを作成する正当な理由がある可能性があります。その理由は、クラスター化されたインデックスが行データの荷物を運び、これにより行密度が非常に低くなる可能性があるためです。すなわち。クラスター化されたキーにない広いフィールドのために、ページごとに 2 ～ 3 行を含めることができますが、クラスター化されたインデックス キーは、たとえば 20 バイトしかありません。クラスター化インデックスとまったく同じキーと順序で非クラスター化インデックスを使用すると、ページごとに 2 ～ 3百のキーの密度が得られます。OLAP/BI ワークロードに典型的な多くの集計クエリは、非クラスター化インデックスによってより効率的に回答できます。これは、単に I/O が数百分の 1 に削減されるためです。

クラスター化されたキーの一部を含む非クラスター化インデックス、または同じキーでも順序が異なる非クラスター化インデックスについては、明らかに多数のクエリに使用できるため、すべての賭けはオフです。

したがって、あなたの質問に対する答えは次のとおりです。

より正確な回答を得るには、テーブルの正確なスキーマと関連する正確なクエリを共有する必要があります。

Answer 2

はい。クラスター化インデックスの列は、非クラスター化インデックスの各インデックスエントリにすでに追加されているため、通常は必要ありません。

なんで？クラスター化されたキーの値は、SQL Serverがデータの行を実際に「検索」できるようにするものです。これは実際のデータへの「ポインター」です。したがって、明らかに、クラスター化されていないインデックスに格納する必要があります。「Smith、John」を検索し、この人物について詳しく知る必要がある場合は、実際のデータに移動する必要があります->これは、クラスタリングキーの値を非のインデックスノードに含めることによって行われます。 -クラスター化されたインデックス。

そのクラスター化されたキー値はすでに存在するため、通常は冗長であり、クラスター化されていないインデックスにその値を明示的に再度追加する必要はありません。それはあなたに何の利益も与えずに単にスペースを浪費するという点で悪いです。

Answer 3

これについては Remus と一緒です。クラスター化インデックスは、実際にはインデックスではありません。データがどのようにページに編成されているかがわかります。(あなたの場合、それは主キーでもありますが、同じである必要はありません)。非クラスター化インデックスにはその行ロケーター情報が含まれているため、はい、冗長です。

ただし、非クラスター化インデックスがカバー していて、データ行のブックマークを使用する必要がない場合は、クラスター化インデックスよりもはるかに効率的に使用でき、効率はデータ行のサイズと非クラスター化インデックスのサイズが増加します。

クエリ ワークロードのアクセス パスを適切に処理できる場合は、いくつかの選択的なカバー非クラスター化インデックスを使用して、クラスター化の選択肢を完全に排除できることがあることがわかりました。 -クラスター化されたインデックス、これで完了です。

Answer 4

100% の答えはありませんが、答えはほぼ間違いありません。

他のインデックスは、(一般に) 結合と並べ替えを支援するためにあります。主キーがすでにインデックス化されている場合、オプティマイザーがそれに基づいて結合できる場合は、それを使用します。

結合/ソートの観点から別のインデックスが必要な場合、インデックス ミックスに PK を含めると、さらにどのような助けになりますか? 以前に PK に基づいて参加できなかった場合は、現在は参加していません。また、並べ替えの助けにもなりません。