すでにコンポジットインデックスの一部である個々の列をインデックスする必要がありますか？

Question

テーブル内の4列にわたる複合ユニークインデックスと、列のうちの2つを個別にフィルタリングするパフォーマンス上の問題を伴うクエリがあります。恐らく疑問な質問ですが、パフォーマンスを向上させるために個々の列をインデックス化する必要がありますか？助けてくれてありがとう！

Answer 1

ジョーの答えが正しくないので、私はこの質問に答えています。

Oracle 9では、スキップ・スキャンと呼ばれる新しいタイプの索引スキャンが導入されました。これにより、先行しない列に索引を使用することができます。詳細はdocumentationで説明されています。

ほとんどのデータベースでは、ほとんどの状況でインデックスが左から右に使用されます。ただし、Oracleのスキップ・スキャン・メカニズムは例外で、他のデータベースの索引付けアルゴリズムを拡張しています。

Answer 2

答えはどちらの列に依存しますか。複合インデックスは、一番左の列のサブセットに使用できます。あなたのインデックスが（A、B、C、D）になっていて、AとBでフィルタリングしているなら、あなたはいいですね。一方、BとCをフィルタリングしている場合は、このインデックスは役立たず、新しいインデックスを作成する必要があります。

Answer 3

あなたはトレードオフを扱います。インデックスが小さいほど処理速度が速くなります。ある例では2つの列だけを試してみましょう。テーブルXに文字列AとBがあるとします。

いいえいいえ、私はA + BのインデックスとB + Aのインデックスを作成します。

これは私にちょうどAまたはちょうどBのためのインデックスを使用することができます。しかし、インデックスを読む際には、SQLエンジンはA + BまたはB + Aのより多くの合計データ量を読み取る必要があります。だから、これはちょうどAまたはBのための1つを持っていた場合よりも遅いです。なぜ4つのインデックスに入れないのですか？あなたはそれを行うことができますが、4つの異なるインデックスを維持する必要があるため、挿入を遅くするようになりました。

正確な正解はありません。他のものは違いに影響します。どのSqlエンジンを使用するか、ベンダーのSQLエンジンのバージョン。これらのアクションの利点と欠点の基本的なダイナミクスを理解する。それをあなたのデータセットとあなたのデータベースを使っているもののより良い理解と組み合わせてください。たとえば、AレコードごとにBレコードが3つ以上あることはめったにありません。複合インデックスを持つことはあまり役に立ちません。エンジンが索引を使用して3つのレコードを検索し、どれを返すかを選択する方が速いでしょう。

結果は異なる場合があります。しかし、これはエンジニアリングのトレードオフの状況です。