すべての外部キー列にインデックスを付けるEntityFramework

EFコードファーストでは、外部キー関係をモデル化する一般的な理由は、エンティティ間のナビゲーション性のためです。 Countryの簡単なシナリオを考えてみましょう およびCity 、次のLINQステートメントに対して積極的な読み込みが定義されています：

var someQuery = 
   db.Countries
     .Include(co => co.City)
     .Where(co => co.Name == "Japan")
     .Select(...);

これにより、次の行に沿ったクエリが発生します：

SELECT *
FROM Country co
INNER JOIN City ci
  ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';

City.CountryIdの外部キーにインデックスがない 、SQLは、JOIN中に国の都市をフィルタリングするために、Citiesテーブルをスキャンする必要があります。

FKインデックスには、行が削除された場合のパフォーマンス上の利点もあります。 親Countryテーブルから、参照整合性はリンクされたCity行の存在を検出する必要があるため（FKにON CASCADE DELETEがあるかどうか） 定義されているかどうか）。

TL; DR

外部キーのインデックスあり 推奨 、外部キーで直接フィルタリングしなくても、結合で必要になります。これに対する例外はかなり工夫されているようです：

• 外部キーの選択性が非常に低い場合、たとえば上記のシナリオでは、countriesテーブルのすべての都市の50％が日本にある場合、インデックスは役に立ちません。

• 実際に関係をナビゲートしたことがない場合。

• 親テーブルから行を削除しない場合（またはPKで更新を試みる場合）。

最適化に関するもう1つの考慮事項は、Clustered Indexで外部キーを使用するかどうかです。 子テーブルの（つまり、国ごとのクラスター都市）。これは、親の場合に多くの場合有益です。親のすべての子行を同時に取得するのが一般的な場所である子テーブルの関係。