ビット列にインデックスを追加すると、挿入が大幅に遅くなりますか？

約100万から500万レコードのテーブルがあります。そのレコードのごく一部では、ビット列の1つが「TRUE」に設定されています。そのレコードをすばやく見つける必要があります。インデックスはこの列の検索を高速化できると思いますが、INSERTを恐れています。したがって、私の質問です。

データベースは一種のデータウェアハウスのように機能するため、多くのSELECTがあり、小さい（1日あたり最大10〜20）が、非常に大きいINSERT（一度に最大20万レコード）があります。データベースへのインポートの時間が長くなるのではないかと心配です。

100万レコードのビットのインデックスは役に立ちません。オプティマイザがこれを使用することは決してなく、維持するために支払うだけです。より良い代替策は、このビットをクラスター化インデックスの左端のキーとして追加することです。

しかし、私は暗闇の中でブラインドショットを行い、あなたが持っているものがキューパターンであると推測します。レコードは、ビットが「TRUE」に設定されたテーブルにドロップされ（つまり、「needsprocessing = true」）、バックグラウンドプロセスが見えるこれらのレコードについては、いくつかの処理を行い、ビットをFALSEに更新します。これは遍在するパターンであり、「パフォーマンス災害レシピパターン」としても愛情を込めて知られています。レコードをテーブルにドロップし、通知（新しく挿入されたレコードIDと同じくらい簡単な場合もあります）を同時にキューにドロップすることをお勧めします。テーブルをキューとして使用するを参照してください。

@MartinSmithが言ったように、SQL 2008にアップグレードする場合は、フィルターされたインデックスが最適なソリューションになります。ただし、平均的には、一般的なケースとして、インデックスを追加するとロード時間が長くなります。小さなインデックスは大きなインデックスよりも少ないです。

私が検討することの1つは、変更可能な既存のインデックスがあるかどうかです。既存のクエリが特定のインデックスを使用している場合、ビットカラムをそのインデックスの最後に追加しても、挿入への影響は最小限に抑えられ、クエリに見られるプラスの効果が得られます。

次に確認することは、「すでに多くのインデックスを持っていますか？」です。「たくさん」が何であるかについての明確で速い規則はありませんが、私が本当に新しいものを本当に必要としない限り、私は通常、10インデックスの規則で行くという制限があります。

最後に、テストインスタンスでテストします。数百万行のテーブルをセットアップし、その上でロードを実行し、インデックスを追加してから、再度ロードを実行して、ロード時間が大幅に増加するかどうかを確認します。

「有意義」が何であるかを本当に決定できるのはあなただけです。読み込み時間に5分を追加することが「重要」なマシンと、数時間の増加を安全に確認できるマシンがあります。

編集：

別のオプションは、テーブルを分割することです。Enterpriseエディションを使用していない場合でも、パーティションビューを使用する必要がある場合がありますが、それでも問題は解決します。あるパーティションにビット0を入れ、別のパーティションにビット1を入れます。どちらか一方のバージョンのみを挿入すると仮定すると、挿入を高速化することもできます。