既存のクラスター化されていないインデックスに列を含めるか、新しいクラスター化されていないインデックスを追加する

Question

テーブルPropsには既に 'CreatedOn'列にnon-clustered indexが含まれていますが、このインデックスは大幅に向上させるために必要です。頻繁に実行されるクエリのクエリパフォーマンス。

この問題を解決するには、

1.付属列として他の列を追加するには、既存のインデックスを変更する？追加の非クラスタに含ま列のインデックスまたは

2を作成また

：

- どのように私の決定は、現在、非クラスタ化インデックスを使用して他のクエリのパフォーマンスに影響を与えるのだろうか？

- 含まれている列を追加するには、既存のインデックスを削除して再作成または変更することをお勧めしますか？

CREATE TABLE dbo.Props(
    PropID int NOT NULL, 
    Reference nchar(10) NULL, 
    CustomerID int NULL, 
    SecondCustomerID int NULL, 
    PropStatus smallint NOT NULL, 
    StatusLastChanged datetime NULL, 
    PropType smallint NULL, 
    CreatedOn datetime NULL, 
    CreatedBy int NULL 
CONSTRAINT PK_Props PRIMARY KEY CLUSTERED 
(
    PropID ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY] 
) ON [PRIMARY] 
GO 

現在のインデックス：

テーブルの簡略化されたバージョンは、問題の指標と共に以下である

CREATE NONCLUSTERED INDEX idx_CreatedOn ON dbo.Props 
(
    CreatedOn ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY] 
GO 

新規または変更されたインデックスに必要な列の全て5です。 foreign keyカラム、smallintとintの混合。ヌル入力可能で、ヌル入力不可。

この例では、includeの列は、CustomerID、SecondCustomerID、PropStatus、PropTypeおよびCreatedByです。いつものように...それが依存

Answer 1

...冗長インデックスを持つ一般的なルールとして

は望ましいものではありません。したがって、他の情報がない場合は、含まれている列を追加してカバーすることをお勧めします。

つまり、元のインデックスは別の「高頻度」クエリ用に構築されている可能性が高いので、天気を判断する必要があります。増加したインデックスページ数がインデックスを使用する既存のクエリに悪影響を及ぼしますそれは現在の状態です。

また、クエリの残りの部分に関連してキールックアップの費用を調べることもできます。キーのルックアップが総コストのほんのわずかな部分でしかない場合、パフォーマンスの向上が大きなインデックスを維持するための費用を相殺することはありえません。