0

私のデータベースには、親子関係であるいくつかのテーブルがあります。例えば：

CREATE TABLE [dbo].[cntnr_header] 
(
    [cntnr_id]            [dbo].[uid]     NOT NULL,
    CONSTRAINT [pk_cntnr_header] PRIMARY KEY CLUSTERED ([cntnr_id] ASC),
);

CREATE TABLE [dbo].[cntnr_content] 
(
    [cntnr_content_id]  [dbo].[uid]       NOT NULL,
    [cntnr_id]          [dbo].[uid]       NOT NULL,
    CONSTRAINT [pk_cntnr_content] 
       PRIMARY KEY CLUSTERED ([cntnr_content_id] ASC),
    CONSTRAINT [fk_cntnr_content_cntnr_header] 
       FOREIGN KEY ([cntnr_id]) 
       REFERENCES [dbo].[cntnr_header] ([cntnr_id]),
);

現在、ご覧cntnr_idのとおり、テーブルの外部キーにはインデックスがありませんcntnr_content。cntnr_content_idチューニング ウィザードを実行したところ、テーブルとcntnr_idテーブルの両方に非クラスター化インデックスを追加することが提案されましたcntnr_content。cntnr_content_idはすでにクラスター化インデックスであるため、これはよくわかりません。なぜこのようなインデックスを推奨するのでしょうか?

CREATE NONCLUSTERED INDEX [_dta_index_cntnr_content_7_821577965__K1_K2] ON [dbo].[cntnr_content]
(
    [cntnr_content_id] ASC,
    [cntnr_id] ASC
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

cntnr_idおそらく、このテーブルの すぐ上に非クラスター化インデックスを追加する必要があると思います。

このシナリオに推奨される方法はありますか? このような関係を持つ特定のインデックスを常に追加する必要がありますか?

多くのクエリは、これら 2 つのテーブルを結合するか、または を指定しcntnr_idて選択を実行します。これも更新/削除の重いテーブルです。更新と削除は常に主キー ( ) で行われます。cntnr_contentcntnr_idcntnr_content_id

4

2 に答える 2

5

クラスター化されたインデックスは、ディスク上にバイナリ ツリーとして物理的に格納されます。通常、読み取り負荷の高いワークロードに最適です。

プロファイラーが cntnr_content テーブルで非クラスター化インデックスを使用しないことを提案している理由は、通常、外部キーを使用してそのテーブルのデータにアクセスするためです。

この状況では、外部キーを使用すると見つけにくい方法でデータがディスク全体に分散されるため、主キーのクラスター化インデックスは役に立ちません。そのため、非クラスター化インデックスの使用が推奨されています。

非クラスター化インデックスに変更すると、データベースは、外部キーを介した検索により最適なオンディスク フォーマットを選択できます。もちろん、これを行うと主キーの検索速度に影響するため、トレードオフになります。ある場合には速度が向上しますが、別の場合には速度が犠牲になります。

于 2013-08-02T19:01:03.020 に答える