1

MS-SQL 2012 では、クエリで常に使用する場合 (つまり、SELECT xx FROM oo WHERE Deleted = 0)、「削除された」BIT フィールドにインデックスを付けるのは理にかなっていますか?

それとも、フィールドが BIT であるという事実には、パフォーマンスの問題のために何らかの自動インデックスが既に付属していますか??

4

6 に答える 6

1

選択性が非常に低いため、必要な条件下では、ビット フィールドのインデックス作成はほとんど役に立ちません。大きなテーブルでのインデックス スキャンは、テーブル スキャンよりも優れているとは言えません。フィルター処理されたインデックスを作成するために使用できる他の条件がある場合は、それを検討できます。

このフィールドがロジックの性質を変更し、常に述語で考慮する必要がある場合は、レポート時にデータを他のテーブルに分割することを検討してください。

于 2013-09-23T18:38:32.623 に答える
1

ビット フィールドにインデックスを付けるかどうかは、この質問への回答で適切に説明されているいくつかの要因に依存します。 231125 へのリンク

于 2013-09-23T18:39:53.667 に答える
1

1、0、またはいくつかの制限された値で構成されるビット フィールドにインデックスを付けると、実際にはその値に一致する行の数が減ります。レコード数が少ない場合はこれでうまくいくかもしれませんが、データ数が多い場合はパフォーマンスが向上する可能性があります。

複合インデックスの一部としてビット列を含めることができます

ビット フィールドのインデックスは、0 と 1 の数に大きな違いがあり、2 つのうち小さい方を検索するシナリオで非常に役立ちます。

于 2013-09-23T18:33:19.973 に答える
0

ビット列がインデックスの最初の位置にある場合、複合インデックスの一部として役立ちます。ただし、selectitn 1 つの値 (select .... where deleted=1 and another_key=?; but never deleted=0) にのみ使用する場合は、フィルターを使用して another_key にインデックスを作成します。

create index i_another on t(another_key) where deleted=1

ビット列が複合インデックスの最後である必要がある場合、インデックスでの出現は役に立ちません。ただし、パフォーマンスを向上させるために含めることができます。

create index i_another on t(another_key) include(deleted)

次に、DBエンジンはインデックスの読み取りとともに値を取得し、ベーステーブルページから値を取得する必要はありません.

于 2016-09-09T08:25:12.523 に答える
0

他の人が述べたように、選択性が鍵です。ただし、常に何らかの値を検索していて、その値が非常に選択的である場合は、フィルター選択されたインデックスの使用を検討してください。

于 2013-09-23T21:28:34.230 に答える
0

クラスター化インデックスの前に出さないのはなぜですか? 削除が増分である場合は、フィル ファクターを下げる必要がありますが、おそらく毎日ですよね? 削除されたレコードが、削除されていないレコードよりもはるかに多くありませんか? そして、あなたが言うように、削除されていないレコードのみを照会します。あ、はい。その列にインデックスを付けるだけではありません。その上に群がります。

于 2013-09-23T23:54:40.440 に答える