1

次のように定義されたかなり高いトラフィック テーブルの最近のレビュー:

CREATE TABLE [dbo].[SomeTable](
    [Id] [bigint] IDENTITY(1,1) NOT NULL,
    [SomeId] [bigint] NOT NULL,
    [Time] [time](0) NOT NULL,
    [InsertTime] [datetime] NOT NULL,
    [SequenceNumber] [int] NOT NULL,
    [OtherId] [int] NULL,
 CONSTRAINT [PK_Tracks] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

次のインデックス定義を明らかにします。

CREATE NONCLUSTERED INDEX [i1] ON [dbo].[SomeTable] 
(
    [SomeId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

-と-

CREATE NONCLUSTERED INDEX [i2] ON [dbo].[SomeTable] 
(
    [SomeId] ASC,
    [OtherId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

この辺はあんまり得意じゃないけど、インデックスはi1余計じゃない？

4

3 に答える 3

2

多分そうでないかもしれません。あなたが最適化担当者である場合、次のクエリにどのインデックスを使用しますか?

select [SomeId]
from [dbo].[SomeTable]

そのクエリがアプリケーションにとって重要な種類のもので、テーブルが大きい場合、そのターゲット インデックスがあると便利です。しかし、i1 によって満たされる可能性のあるクエリは、i2 でも (おそらくより高価に) 満たされる可能性があるという点で、あなたは正しいです。

于 2012-06-18T19:05:13.773 に答える
1

はい、冗長です。誰かが既存のインデックスを冗長にするかどうかを確認せずに新しいインデックスを追加すると、この種の状況に陥ることがよくあります。

明らかに冗長なインデックスが役立つ状況について説明しているこの投稿を読む価値があることがわかるでしょう。ただし、テーブルには大きな列が含まれていないため、適用されません。

参考までに、このブログでは、データベースから冗長なインデックスを削除する方法について説明しています。

于 2012-06-18T15:28:17.673 に答える
1

i2インデックスの冗長性を重み付けするときは、余分な列の幅だけでなく、最初の列との関係でその粒度についても考慮する必要があります。

OtherId列のすべての値に対して多くの値があり、多くの値を取る場合、whereSomeIdのみを使用したクエリはSomeId、一見冗長なインデックスを使用しない場合よりも時間がかかります。

于 2013-06-06T07:28:13.333 に答える