スター結合の計画と統計
結合計画は、結果テーブルのカーディナリティの見積もりに基づいています。そのため、統計情報が正しくないと、カーディナリティを正確に見積もることはできません。
スター結合のカーディナリティは、小さなテーブルの結合結果と大さなテーブルの結合列の選択性に基づいて見積もられます。したがって、スター結合を含んだ問合わせの最適な結合計画を選択するためには、次のことを考慮する必要があります。
- すべてのテーブルのプライマリ[AMP]インデックス、および問合わせで使用される各インデックスに関する統計情報を収集しなければなりません。
- インデックス以外の列に制約が指定された場合には、それらの列に関する統計情報も収集しなければなりません。
スター結合のハッシュ シノニムの回避
プライマリ インデックスを構成している列によっては、ハッシュ シノニムが発生する場合があります。ハッシュ シノニムは、プライマリ インデックスを桁数のSMALL INTEGER列でのみ構成したときに発生しやすくなり、常に問合わせの性能が低下します。
性能向上のためのデータ型の変更
可能なかぎり、結合される列が同じ(データ型の)ドメイン(数値であれば、同じサイズ)から成るように、テーブルや問合わせを設計する必要があります。結合される列のデータ型が違う(数値であれば、サイズが違う)場合には、どれか1つのテーブルのタイプの定義を変更することによって、結合の性能が向上するはずです。
結合条件でインデックスを指定しない場合には、いずれのテーブルの変更も不要です。そのような場合には、結合される列に同じデータ型を指定すれば、中間の結合結果用にプライマリ インデックスが使用されるため、再ハッシングが不要になります。
しかし、結合の中でインデックスが使用できる場合で、かつインデックスのいくつかの列のサイズが小さい場合には、いずれかのテーブルへの変更が必要になる場合があります。大きい方のテーブルのデータ型を使用する結合列の定義に合わせて小さい方のテーブルを変更すると、パフォーマンスが向上する場合があります。
例えば、次の結合条件を、table_1.NUPIは型付きSMALLINTであり、table_2.NUPIは型付きINTEGERであると指定したとします。
table_1.NUPI = table_2.NUPI
table_1のテーブルの方が大きい場合は、table_2.NUPIをSMALLINT型に変更することを検討してください。ただし、table_2のテーブルの方が大きい場合は、table_1.NUPIをINTEGER型に変更することを検討してください。
1つのインデックス オペランドを使用するよう、条件式の変更
結合条件の片方に式とインデックスが含まれている場合には、一般的に、インデックスが単独の演算項である場合のように性能が高くありません。片方のインデックスが他のどの式からも排他的で、単独の演算項になるように、等号を変更してみてください。
例えば、次の条件式を考えてみてください。
次の例では、条件は式内でのプライマリ インデックスtable_2 (table_2.NUPI)を使用して記述されています。
table_1.x = table_2.NUPI - 1
これは条件を指定する次善の策です。
次の条件の指定は最適になります。これは、table_2のプライマリ インデックスを式から分離し、計算式の両辺に単純な同一の条件(+1)の代数的加法を使用して、分離したプライマリ インデックスを等価条件の反対側へ移動させているためです。
table_1.x + 1 = table_2.NUPI