複合主キー、たとえばPrmIDとTypeを使用して新しいテーブルを作成したため、新しい複合クラスター化インデックスが作成されました(PrmIDが最初です)。Typeに別の非クラスター化インデックスを追加します。
私の質問は、Typeで任意のステートメントを実行するクエリ(GROUP BYなど)を生成するとき、SQLエンジンは非クラスター化インデックステーブルまたはPKクラスター化インデックス(この種のクエリではより高価です)を使用していますか?
複合主キー、たとえばPrmIDとTypeを使用して新しいテーブルを作成したため、新しい複合クラスター化インデックスが作成されました(PrmIDが最初です)。Typeに別の非クラスター化インデックスを追加します。
私の質問は、Typeで任意のステートメントを実行するクエリ(GROUP BYなど)を生成するとき、SQLエンジンは非クラスター化インデックステーブルまたはPKクラスター化インデックス(この種のクエリではより高価です)を使用していますか?
- 編集 -
ありがとう、マーク、私はそれを逃した...
-- 編集終了 --
2 番目に、PrimID は本当にテーブル内で一意ではなく、Type との組み合わせでのみ一意ですか? テーブルで PrimID が重複していない場合は、複合 PK にすることを再検討してください。
第 3 に、これらのタイプの質問に答える最善の方法は、クエリの実行計画を確認することです。SQL がどのように計画を処理すべきかについてはお答えできますが、SQL Server はデータベースやハードウェアなどのデータに基づいて、さまざまな状況に合わせて実行計画を変更します。
実行計画は次のようになります。
どの idex が使用されているか、どのように使用されているかが正確に示されていることがわかります...実行計画を理解するための優れた紹介を提供する記事を次に示します。
クエリがどのように見えるか、どの列がアクセスされるか、カバーされているかなどによって異なります
タイプに対する単純な GROUP BY では、ほとんどの場合、NC インデックスが使用されます。他の列を使用すると、ブックマップ/キー ルックアップを取得するか、インデックスが無視され、非効率的な PK スキャンが発生する可能性があります
私の理解では、マルチフィールド インデックスがあり、クエリがインデックスの最初のフィールドを使用していない場合、そのインデックスは使用されません (難しすぎる、効率的でないなど)。その後、他のインデックスが使用されます。
ただし、これを確実に知るには、実行計画、または推定実行計画だけでクエリを実行してください。SSMS を使用している場合、ツールバーのボタンを押すだけで簡単に実行できます。青と緑の 3 つの小さな箱が逆 L 字型になっているようなものです。これにより、使用されているインデックスが正確にわかります。また、実行計画はクエリの存続期間中に (データが変更されると) 変更される可能性がありますが、この回答ではそうすべきではありません。