主キー（> 1列）のインデックス（1列）は有用ですか？ （SQL）

Question

私は40k行以上のテーブルと、このテーブルに2列からなる主キーを持っています。

これらの主キー列のうちの1つの列に別々のノンクラスター（一意ではない）索引を付けると、他のPK列を使用せずにこの列の照会を高速化できますか？または、SQL Serverは主キーの1つの列にのみアクセスするために主キーを同様に効率的に使用しますか？

プライマリキーは一意のインデックスですが、その質問とは関係がありません。私は、PK列の1つからデータにアクセスするときとは対照的に、複数の列にまたがるプライマリキーを心配しています。 。

Answer 1

PKを想定することである（この順序で）フィールド1、フィールド2

• クエリフィールド1上のフィルタは、そのPK指数（インデックスシーク）から利益を得ることができること。
• Field1とField2でフィルタリングするクエリは、そのPKインデックス（インデックスシーク）を利用できます。
• Field2でフィルタリングするクエリは、そのPKインデックス（インデックススキャン）の恩恵を受けることはできません。

最後のケースでは、Field2で別のインデックスを検討することがあります。たとえば、次のような場合はもう少しです。 PKフィールド以外のテーブルの他のフィールドを返しています。この場合、PKがCLUSTERED（デフォルトではPK）の場合、データは既に索引に入っています。しかし、NONCLUSTEREDインデックス（Field2にインデックスを作成した場合など）では、インデックスを取得して検索を実行して、クエリで返される他のフィールドを取得する必要があります。したがって、NONCLUSTERED索引の列をINCLUDEするかどうかを決定する領域に入ることができます。

これを読んで少しお読みになることをお勧めします。スピードアップする価値があります。