DB2 LUW データベースのいくつかのインデックスの作成に取り組んでいます。ランディング ページにいくつかの新しいクエリを実装し、パフォーマンスを上げようとしています。いくつかのテーブルで、順序付けが最適でないように見えるいくつかのインデックスを見つけました。つまり、選択性が非常に低い列が、選択性が高い列よりも先に表示されます。それらをより良いバージョンに置き換えることを検討していますが、結合インデックスについて少し混乱しています。
少し背景を説明すると、クエリは少し大きくなる可能性がありますが、それほど複雑ではありません。
SELECT
--About a dozen fields from TABLE A--
--A few fields from joined tables--
FROM
TABLE A
--A few inner join/left joins, mostly on A.ID1 and A.ID2, BIGINT generated keys--
WHERE
A.ONE = :x
AND A.TWO IN (:y)
AND A.THREE IN (--uncorrelated suquery--)
AND A.FOUR IS NULL
AND (A.FIVE BETWEEN :date1 AND :date2
OR
A.SIX = 'STUFF')
ORDER BY A.SEVEN
あなたはアイデアを得る。これらの列のほとんどのカーディナリティは非常に明白であり、選択性の観点からインデックスを構成するのは簡単です。WHERE 句で使用されるすべてのフィールドに適切な順序でインデックスを付けると、処理速度が大幅に向上します。ただし、結合列は少し混乱します。
A.ID1 や A.ID2 など、多数の列が既にインデックス化されており、これらが一緒になってテーブルの主キーを形成します。これはクラスター化インデックスだと思います。また、それ自体で索引付けされた外部キー ID ペアもいくつかあります。私が疑問に思っているのは、結合で使用されるこれらの列を、WHERE 句のフィールドをカバーするインデックス内に含める必要があるか、または有用でさえあるかどうかです。結合された列にはインデックスを付ける必要があり、WHERE 句の列にはインデックスを付ける必要があるとよく言われていますが、それらは別々ですが。この件に関して決定的なもの（または「通常は良いアイデアですが、常にではありません」）を実際に見つけることができませんでした. この種の一般的な慣行は何ですか？クエリが重要な場合は、インデックスを分離するか、すべてまとめますか?
また、A.SEVEN は一意の値を持つ列ですが、ORDER BY でのみ使用しています。繰り返しますが、決定的なものは正確には見つかりませんでしたが、ORDER BY (および SELECT ステートメント) でのみ使用されているという事実は、カーディナリティに関係なくインデックス内の配置に影響します (つまり、最後に配置されます)。フィルタリングには使用されず、並べ替えのみに使用されるか、一意性のために先頭に配置されるため、インデックスの
後から考えると、列 A.FOUR は null のみがチェックされます。これは、null 以外のデータのカーディナリティは無関係であり、null 値のみを探しているため、インデックスの後半に配置する必要があることを意味しますか? A.FOUR はほとんど null である可能性がありますが、null でない場合はほとんどが一意になります。