SQL Serverクエリのパフォーマンスwhere節

Question

私は10 000行のようなテーブルを得ました。

declare @a table 
(
    id bigint not null, 
    nm varchar(100) not null, 
    filter bigint 
    primary key (id) 
) 

選択は、4-5結合で、x秒かかる。 where句が追加されると、現在は3x秒かかります。 where句：

非クラスタ化インデックスを列に適用しましたが、パフォーマンスは10％しか向上しません。

ヒント？

編集：フィルタ列を追加するとパフォーマンスが問題になります。すべての結合が主キー上にあります。

Answer 1

私はこれには、いくつかの考えを持っている：

1. チャンスはあなたの加入がtable.idに参加しているということです - 主キーであり、インデックス持っている - ビンゴ - （値は一意であるため）、高い選択性を。索引付けされていると、オプティマイザは実際にはジョインで使用されるときにこの表へのアクセスoptimizeにアクセスできます。

2. 私は100％確信していませんが、filterにインデックスがないか、または選択的ではありません。索引がない場合、オプティマイザは表スキャンを使用します。インデックスを持っていても十分に選択的ではない場合は、とにかくテーブルスキャンを使用します。スキャンは高価です。

3. インデックスがfilterの場合でも、オプティマイザは述語がORではありません。基本的にORを使用すると、オプティマイザはインデックスシークの代わりにインデックススキャンを使用して終了する可能性があります。この代わりに、@ sut13として@filder = ISNULL(Filter, @filderを試してみてください。あなたは1を持っていると私は示唆しているようORを使用しないように、あなたのwhere句を調整していない場合filterにインデックスを追加しますので、パフォーマンスを向上させるために

。また

：

あなたは参加し4-5でwhereフィルター付きクエリに等しいまたはクエリよりも良好に機能するために期待するべきではありません。結合を含むクエリがより選択的であり、インデックスの利用率が向上する場合は、より良いパフォーマンスが得られるでしょう。

Answer 2

フィルタ列の索引が不足している可能性があります。テーブルスキャン。唯一の方法は、クエリの実行計画を確認することです。これは、オプティマイザがクエリを使って何をしているかを示し、通常、十分な情報を提供して、それがなぜそれをしているのか、それを修正するために何をする必要があるのか​​を理解することができます。

おそらく、フィルタ列にインデックスが必要です。しかし、 'OR filter IS NULL'を指定すると、データに含まれるヌル値の数に応じてスキャンが実行される可能性があります。

説明したようにISNULLを使用すると、残念なことに、それは列の関数であり、おそらく（最初にデータをフィルタリングするために使用できるWHERE句の中の他の列など）結果スキャンではなく、シークで。