2

主キーと 2 つの外部キーを持つテーブルがあり、どちらも NULLS を許可しています。

2 つの列ごとに個別にインデックスを作成すると、クエリは約 2 ~ 3 秒実行され、約 300000 行が返されます。

その2つの列に対して複合非クラスター化インデックスを作成すると、同じ数の行に対して約10分間クエリが実行されます。

次のように、2 つの列が WHERE 条件に表示され、OR 句で機能することに注意してください。

Select 
    SomeColumn
From
    SomeTable
Where 
    FirstColumn = x OR SecondColumn = x

クエリが実行されたプラットフォームは SQL 2008 R2 です。

その 2 つのケースで実行時間にこのような違いがあるのはなぜですか?

4

2 に答える 2

2

2 つの個別のインデックスがあり、それらの 2 つの列のみがWHERE句にある場合、オプティマイザは両方を効率的に使用して、必要な行 (おそらくINDEX SEEK) を決定できます。

複合インデックスは最初のインデックス列でソートされ、次に 2 番目のインデックス列でソートされるため、複合インデックスはあまり適していません。ORしたがって、あなたが得たように、条件の最初の列に役立ちます。2 番目の列の行を決定するには、適切なインデックスがないため、オプティマイザは完全なテーブルをスキャンする必要があります。

このシナリオで大きなテーブルを取得した場合、通常、質問したような単純なクエリでは単一のインデックスの方が高速です。実際には、選択した列、クエリの複雑さ、カバーするインデックスなどにも依存します。

私は自分でこの問題を抱えていました。参照:結合されたインデックスと複数の単一インデックスとフルテキスト インデックスのクエリ パフォーマンスを参照してください。

于 2013-01-16T11:49:18.190 に答える
1

ポイントは、インデックスの列の順序が重要です

create table #temp (col1 int, col2 int )
create nonclustered index index1 on #temp(col1, col2)

と同じではありません

create nonclustered index index2 on #temp(col2, col1)

コメントのように、クエリの実行計画を投稿します

または、複合インデックスの列の順序を変更して、クエリを再実行します

コメントで述べたように、私の推測では、クラスター化されていないインデックスが 2 つある場合、オプティマイザーはそのうちの 1 つを使用して、それらを削除し、データ選択性の低い最初の列で複合インデックスとして再作成すると、インデックスは使用されず、クエリの実行時間は苦しむ

クエリを投稿すると、はるかに簡単になります

于 2013-01-16T11:36:17.623 に答える