含まれる列とフィルターされたインデックス

現在、tb_tranfersという名前のテーブルを使用しています。このテーブルには4,000万行あり、サイズは最大26 GB（11 GBのデータ、15 GBのインデックス）です。

行の10〜15％が一時削除された行です（DeletedDateはnullではありません）。アプリケーションはDeletedDateがnullである行のみを使用します。このテーブルへのすべてのクエリには、その効果に対する句が含まれます。

このテーブルには15のインデックスがあります。欠落しているインデックスDMVには、削除された日付を含む列としてインデックスを作成するための提案が含まれています。

WHERE DeleteDdate IS NULL11個の整理されていないインデックスすべてにフィルター処理されたインデックスを使用することは役に立ちますか？または、DeletedDate列をインクルード列として持つ方が良いでしょうか？

はい、11個すべてのNCインデックスをフィルター処理されたインデックス（CREATE INDEX ... ON ... WHERE DeletedDate IS NULL）に変更すると役立ちます。この方法には2つの利点があります。

• クエリオプティマイザは、すべての行がすでにこれらのインデックスから来ることを知っているんそれはダブルチェックDeletedDateにクラスタ化インデックスを検索する必要はありませんので、DeletedDateにクエリフィルタを満たします
• すべてのNCインデックスのサイズが10〜15％小さくなり、検索に必要なメモリと入出力操作が少なくなります。

トレードオフは、ソフト削除された行を管理するすべてのクエリ（およびいくつかのクエリが必要です。それ以外の場合、行が存在するのはなぜですか？）では、これらのNCインデックスを使用できません。

常にDeletedDate IS NULLクエリでフィルターを使用している場合、はい、フィルターを追加することでパフォーマンスが大幅に向上する可能性があります。

エンジンが関連する行を見つけるためにチェックするページがはるかに少ないため、IOが少なくなります（速度が向上します）。

それを追加するINCLUDEDフィールドはなり役に立ちません。常にフィルターに含めるため（おそらくSELECTリストに追加しないため）、フィールドをとして追加した場合、そのフィールドは参照されませんINCLUDE。

行の85〜90％でDeletedDateがNULLであるため、DeletedDateのみで構成されるインデックスの選択性がSQLでこのインデックスを使用するのに十分であるとは考えられません。ただし、他のより選択的な列と組み合わせて使用​​する場合、既存のインデックスにDeletedDateを追加すると、インデックスの全体的な選択性が向上するため、いくつかの利点があります。

JNKが言うように、SELECT句で使用しない限り、DeletedDateはインデックスのカバーにはほとんど役に立ちません。

データよりもインデックス用のストレージがすでに多い場合、既存の15のNCインデックスに冗長性があるかどうかを確認することもできます。