このテーブルには 60 のフィールドがありますが、そのうちの 16 はインデックス付き + 1 つのプライマリ フィールドです。
これは少し過剰に見えますが、これらすべてのインデックスが本当に必要な場合は問題ありません。
インデックスは無料ではありません。追加のインデックスごとにスペースが必要であり、データを検索するときの高速化と引き換えに、データを変更するときにメンテナンス1が必要です(正しく使用されている場合)。特定のケースに適したトレードオフを特定するのはあなた次第です。
これらすべてのインデックスを備えたこのような大きなテーブルを用意することをお勧めしますか?
ほとんどの場合、FK にインデックスを設定することをお勧めします。これにより、DBMS は FK を良好なパフォーマンスで維持できます。具体的には、親行が削除されるか、参照されるキーが更新されるたびに、DBMS は子行を検索する必要があります。理論的には、親を削除/更新しない場合、FK のインデックスも実際には必要ありません。
これらのインデックスは JOINin に役立ちます (通常はそうです) が、実際には JOIN の方法と DBMS のクエリ プランナーの能力に依存します。2
このような大規模なプロジェクトでインデックスを使用する最良の方法は何ですか?
パフォーマンスが重要なクエリごとに、クエリの実行計画を注意深く調べ、代表的な量のデータで実際のタイミングを測定します。クエリが小さなテーブルで一方向に実行されるからといって、テーブルが大きくなったときに同じ方法で実行されるとは限りません。
最後になりましたが、 Use The Index、Luke! を読むことを強くお勧めします。
1行がテーブルに挿入されるたびに、DBMS はインデックス B ツリーに対応するキーを挿入する必要があります。行が削除されると、キーはインデックスから削除されます。インデックス付きフィールドが更新されると、古いキーを削除して新しいキーを挿入する必要があります。テーブルのインデックスが多いほど、そのテーブルの行を INSERT / UPDATE / DELETE するたびに、DBMS がこの「インデックスのメンテナンス」に費やす時間が長くなります。
2 JOIN を実行するには多くの方法があります: さまざまな順序でのネストされたループ、マージ結合、ハッシュ結合... 異なる戦略では、異なるインデックスまたは異なる種類が必要になる場合があります。インデックスの数 (たとえば、B ツリーはハッシュ結合にはあまり適していません)。すべての DBMS が、これらの戦略をすべて使用できるわけではなく、理論的には使用できるすべてのケースで既存のインデックスを使用できるわけではありません。したがって、ある DBMS でうまく機能するインデックス作成戦略が、別の DBMS でもうまく機能するとは限りません。また、場合によっては、インデックスを保持することもできますが、「クエリ ヒント」を使用するか、特定の DBMS のクエリ オプティマイザーに対して「使いやすい」構文を使用して、DBMS を正しい方向に「微調整」する必要があります。同等だがより人間が読める構文が存在する可能性があります。たとえば、古いバージョンの MySQL では、ループの逆順またはマージ結合の方が高速な場合でも、ネストされたループの内側として常に IN サブクエリを実行していました。それか'MySQLの下で（MySQL 5.6で修正されたと聞いていますが）。OTOH、Oracle で IN を JOIN として書き直すことはあまり役に立ちません。Oracle は、構文上の違いがある場合でも、同等のクエリを同等に実行するのがはるかに優れているためです。