相関列の影響

索引の最善のマッチング列での列相関

以下の照会は、 カリフォルニア州、Fresno の部門 A345 内の女性 (F) の行を選択します。 表には、索引 1 (CITY,STATE,ZIPCODE) および索引 2 (DEPTNO,SEX) の 2 つの 索引が定義されています。

Query 1
 
SELECT ... FROM CREWINFO WHERE
  CITY = 'FRESNO' AND STATE = 'CA'         (PREDICATE1)
  AND DEPTNO = 'A345' AND SEX = 'F';       (PREDICATE2)

2つの複合述部 (「PREDICATE1とPREDICATE2」というラベル)、それらの実際のフィルター効果(選択された行の比率)およびそれらのDb2フィルター係数を考慮します。 適切なカタログ統計が収集されていない限り、 フィルター係数は、 述部の列が完全に独立している (相関していない) ものとして 計算されます。

述部の列が相関しているが、相関がカタログ統計に反映されていない場合、実際のフィルター操作は、Db2フィルター係数とは大きく異なるものになります。 以下の表は、実際のフィルター効果とDb2フィルター係数がどのように異なるか、およびその相違が索引の選択とパフォーマンスにどのように影響するかを示しています。

Db2は、一致する列の最小のフィルター係数によって部分的に決定された、最少行を戻す索引を選択します。 フィルター係数がアクセス・パスに影響を与える唯一のものであるとします。 列 CITY と STATE を組み合わせたフィルター操作の効率がよさそうであり、 2 番目の索引の列のマッチングはそれほどよいものではないようです。 これらの計算に基づいて、Db2は索引1を照会1のアクセス・パスとして選択します。

問題は、列 CITY および STATE のフィルター操作の効率が良くないことです。 列 STATE では 、ほとんどフィルター操作されません。 列DEPTNOおよびSEXは行のフィルター処理のより良いジョブを実行するため、Db2は索引1より索引2を優先させる必要があります。

索引の索引スクリーニング列での列相関

索引スクリーニング に使用された非マッチング索引列にも相関が起こる場合があります。 詳細は、 一致しないインデックススキャン（ACCESSTYPE='I'および MATCHCOLS=0 ）を参照してください。 索引スクリーニング述部は、索引のスキャン中に修飾するデータ行を減らすの に役立ちます。 しかし、索引スクリーニング述部に相関関係があれば、 フィルター係数が示すほどの数のデータ行をフィルターしません。 これを説明するために、 テーブル1 に次のインデックスを使用してクエリ1を実行します

Index 3 (EMPNO,CITY,STATE)
Index 4 (EMPNO,DEPTNO,SEX)

索引 3 の場合、述部 1 の列 CITY と STATE が相関関係にあるため、 スクリーニング述部で予測されたほどには索引アクセスが改善されず、 したがって、索引 4 を選択するほうが良いかもしれません。 (索引スクリーニングは、マッチング列が 0 より大きい索引にも起きることに注意 してください)

複数の表の結合

Query 2
SELECT ... FROM CREWINFO T1,DEPTINFO T2
   WHERE T1.CITY = 'FRESNO' AND T1.STATE='CA'          (PREDICATE 1)
   AND T1.DEPTNO = T2.DEPT AND T2.DEPTNAME = 'LEGAL';

結合ステートメントで表がアクセス順序によりパフォーマンスが影響を 受けます。 PREDICATE1 の組み合わせフィルター操作の見積もりは、実際のフィルター係数より 低くなっています。 それで、表 CREWINFO の方がアクセスされた最初の表よりも予想より 効率的なようです。

表 CREWINFO の見積もりが小さいためネスト・ループ結合が 結合方式に選択されます。 しかし、Predicate1が見積もりと同じ数の行をフィルターに掛けないために、表CREWINFOから多数の行が選択されている場合は、別の結合方式または結合シーケンスがより良くなる可能性があります。