0

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

いくつかの注意事項:

  • A.ID1 と A.ID2 だけにインデックスがあります。これは主キーであるため、クラスター化されたインデックスである可能性があります。
  • A.SEVENに目次あり
  • WHERE 句の残りのフィールドのインデックスを修正しています

したがって、すべての結合/フィルター/順序列にインデックスが付けられます。問題は次のとおりです。それらをすべて 1 つのインデックスに結合する必要がありますか、それとも個別のままにしておく必要がありますか? A.SEVEN を同じインデックスに配置した場合、選択性に従って配置したいですか、それともフィルタリングがなく、並べ替えのみであるため、無関係でしょうか?

編集:少なくとも私が使用しているクエリでは、OR句の代わりに高速な代替手段を使用していることに気づきました:

CASE WHEN (first statement) THEN 1 
WHEN (second statement) THEN 1 
ELSE 0 
END = 1

これは一部のクエリでは驚くほど効果的ですが、OR 句と比較してインデックスの使用に影響するかどうか、またはどのように影響するかはわかりません。さらに、ONE から FOUR までを選択性の順に編成するのが最適ではないでしょうか。つまり、FOUR に 12 個の異なる値しかなく、ONE に 10k しかない場合、ONE をインデックスの先頭に配置するのが最適です。

4

1 に答える 1

0

私は、DB2 固有のインデックス処理について詳しく知りません。しかし、それが他のデータベースと同様であると仮定すると、最終的な並べ替えにインデックスを使用できるとは思えません。

where句に基づくこのクエリの適切なインデックスはA(one, two, three, four). その後、条件により と のfive間でスタックします。これらのいずれかをインデックスに入れることができます。両方を入れてもおそらく違いはありません.最初のものだけが使用され、2番目のものはインデックスのその部分をスキャンして他の条件を満たす行を見つけることによって解決されます.sixor

つまり、 に到達する前に索引の有用性が終了しますseven。

DB2 が本当に洗練されている場合、2 つのインデックス A(one, two, three, four, five)と A(one, two, three, four, six). 繰り返しになりますが、or条件により、インデックスはorder by.

等式条件のため、one、two、three、およびfourはインデックス内で任意の順序になります。1つの注意点があります。indb2 がサブクエリで条件をどのように扱うかわかりません。にインデックスを作成したいと思いますA(one, two, four, three)。

于 2013-04-19T18:38:48.773 に答える