私はそれが（例えば、10未満）のレコードが非常に少ないルックアップテーブルを持っている場合、それが接続されている別のテーブルの外部キーにインデックスを置く必要がありますか？その点では、ルックアップテーブルでもプライマリキーのインデックスが必要ですか？ルックアップテーブルの外部キーは常にインデックスに登録する必要がありますか？
特に、インデックスを維持するオーバーヘッドを上回るパフォーマンス上の利点はありますか？そうでない場合は、スピード以外の利点はありますか？
注：ルックアップテーブルの例は、注文状況かもしれないが、タプルは以下のとおりです。
1 - Order Received
2 - In Process
3 - Shipped
4 - Paid
トランザクションシステムでは、クエリオプティマイザがおそらくそれを使用しないため、そのような列（つまり、低カーディナリティ参照列）にインデックスを置くことに大きなメリットはありません。また、索引を更新する必要があるため、表への書込み時に追加のディスク・トラフィックも生成されます。したがって、トランザクションデータベースのカーディナリティFKが低い場合、通常は列のインデックスを作成しないほうがよいでしょう。これは特に大量生産システムに適用されます。
参照整合性のためにFKを依然として使用していて、ルックアップテーブルがほとんど常にキャッシュされるため、小さな参照テーブルのFK参照でI/Oが生成されない可能性があることに注意してください。
しかし、何らかの理由で複合インデックスに列を含めることができます。おそらく、一般的に使用されるクエリのカバーインデックスを作成することができます。
バルクロードが頻繁に行われるテーブル（データウェアハウスなど）では、インデックス付きの列が多数ある場合、インデックス書き込みトラフィックはテーブルの負荷よりもはるかに大きくなります。索引が存在する場合は、バルク・ロードのためにFKと索引をドロップまたは使用不可にする必要があります。
スタースキーマでは、SQL Server上であっても、カーディナリティの低い列にインデックスを付けることでいくつかの利点が得られます。高度に選択的なクエリ（つまり、クエリオプティマイザが返した行集合が小さいと判断したクエリ）を実行する場合、インデックス交差と呼ばれる手法を使用する「スタークエリ」プランを実行できます。
一般に、スター・スキーマの問合せ計画は、ファクト表の表スキャン、またはファクト表をブックマークしてより小さな行セットを戻す高度に選択的なプロセスに基づいている必要があります。ファクト表のI/Oを実行する前に選択を解決できるので、後者のタイプの問合せでは索引の交差が効率的です。
ビットマップ索引は、それらをサポートするOracleなどのプラットフォームでは、カーディナリティの低い列に対して実際のメリットがありますが、SQL Serverにはありません。それでも、SQL Serverのスタークエリプランには、低カーディナリティインデックスが引き続き参加できます。
私の個人的な意見は、あなたが...それは今小さいことが、常に成長している、あなたのテーブルを予想することがなければならないことですサイズで。優れたデータベーススキーマは、より多くのレコードで容易に成長します。外国キーは、ほとんどの場合、常に良いアイデアです。
外部キーを持つテーブルのサイズは、確かに大きくなります。注文ステータステーブル...あまりそうではありません。 –
+1成長を予測し、クエリープランに関する意思決定に必要なツールをdbエンジンに提供します。インデックスを必要としない場合は無視し、小さなテーブルのインデックスのコストはほとんどありません。 – RedFilter
はい、常にインデックスがあります。
最近のデータベース管理システム（DBMS）のクエリオプティマイザは、（1）実際に列のインデックスから読み取る、（2）フルテーブルスキャンを実行する、どちらが高速であるかを判断します。
索引を使用するには、表のサイズ（行数）を「十分に大きく」する必要があります。
テーブルにレコードが4つしかない場合は、インデックスが使用されますか？ –
@Robert Harvey - レコードが4つしかない場合はおそらく、テーブル全体が単一のデータページ上にあるため、インデックスにはI/Oは保存されません。一方、索引は変更されないわずか4行しかないので、テーブルが後で増加する場合に追加することができます。 –
SQL Serverでは、プライマリキーが既に存在しない場合（クラスタ化されたインデックス）、クラスタ化インデックスです。
意味、ルックアップテーブル上のインデックスの問題または無インデックスはおそらく無関係でしょうか？ –
問題は正当なものではなく、外部キーは自動的に索引付けされません。 – HLGEM
ルックアップテーブルにプライマリキーのインデックスが必要な場合は、私は答えていました。 – kemiller2002
両方に該当します。常にの経験則としてインデックスを作成します。
ポイント：
しかし、必ずしもそうではありません。
親テーブルが複数あるOLTPテーブル（1日に500万行+）があります。私たちが必要とするところにあるFK列にのみ索引付けします。いくつかの親テーブルでは、削除/キーの更新は想定されていないので、必要な作業量と使用されるディスクスペースが減ります。
SQL Server 2005 dmvsを使用して、インデックスが使用されていないことを確認しました。私たちはまだFKを持っています。
SQLの専門家を引用するには：「（プライマリ）キーがない場合はテーブルではありません」 - そのような小さいルックアップテーブルでも*常にプライマリキーが必要です。 –