主キーがクラスタ化インデックスの上に

を非クラスタ化インデックスを好むためのいずれかの理由は、私は別にPK_MyTable NONCLUSTEREDインデックス上からこの主キーがクラスタ化インデックスの上に

CREATE TABLE [dbo].[MyTable](
    [MyTableId] [bigint] IDENTITY(1,1) NOT NULL, 
    [SomeTable2Id] [bigint] NOT NULL, 
    [SomeTable3Id] [bigint] NOT NULL, 
    [SomeData] [smallint] NOT NULL, 
CONSTRAINT [PK_MyTable] PRIMARY KEY NONCLUSTERED 
(
    [MyTableId] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY] 
) ON [PRIMARY]

のように定義されているテーブルをしました、BIGINTとアイデンティティである、私はいくつかの他のNONCLUSTEREDをしましたSomeTable2IdとSomeTable3Id上のインデックス

私は上記のCLUSTEREDインデックスを作成するほうが理にかなっていると思いますが、CLUSTEREDインデックスを作成せず、代わりにNONCLUSTEREDを作成することについての正当な理由はありますか？

PSこれらのトピックについては多くの質問がありますが、関連するものは見つかりませんでした（上位20リスト）。これが尋ねられた場合は、関連する質問の投稿に私をリダイレクトしてください。

EDIT：MyTable他の2つのテーブルSomeTable2とSomeTable3をマッピングしていると私のクエリは、他のIDを取得するためにSomeTable2IdまたはSomeTable3Idと要求のいずれかを持っているほとんどの時間の代わりに複合キーを有するので、私たちはこのMyTableIdを持っている場合を考えてみましょう。したがって、このテーブルのこのような使い方では、MyTableId以上のクラスタ化インデックスの作成、またはSomeTable2IdおよびSomeTable3Id以上の2つのノンクラスタードインデックスの作成は、本当に必要ですか？

出典

2011-07-19 Ankush

私は、あなたは間違いなくクラスタ化インデックスでは、あなたのキーとしてMyTableIdを持つべきだと思いますテーブルが実際にどのように使用されているかについての詳細はありません。

クラスタ化インデックスまたはヒープテーブルのいずれかを選択していることに注意してください。クラスタード・インデックスはテーブルのインデックスではありませんが、クラスタード・インデックス・キーに基づいてテーブルがBツリーに格納されていることを示します。

両方の種類の表では、非クラスター化インデックスも使用できます。

読み取りパフォーマンス（特に幅の広いテーブル）では、クラスタ化されていないインデックス（列が含まれている可能性があります）は、利益を求める場所になります。

出典

2011-10-15 02:30:20

ありがとうございます。私は一つの懸念があります。私の場合、このテーブルは2つの異なるテーブル間のマッピングテーブルとして機能します。私はルックアップのためにこのテーブルを使用しています。ほとんどの場合、私は主キーを使用しません。それは違いがありますか？ – Ankush

@Ankush主キーには常に索引があります（表のクラスタード索引の選択であるかどうかにかかわらず）。他の方法でアクセスする場合は、それらのキー（クラスタ化または非クラスタ化）のインデックス作成も検討してください。クラスタリングインデックスの選択は、一意で、狭く、静的で、増加する必要があります。いくつかの候補がある場合は、範囲問合せで使用される可能性が最も高いものを選択します（そうでない場合は、おそらくID）。 –

私はそれを理解していますが、これは上記のコメントの私の懸念に対処していません。私はあなたがそれを意味すると思います**違いはありませんし、プライマリキーでクラスタードインデックスを参照してください。右？ – Ankush