Oracleでルールベースでの複合索引

質問

数十万件のデータをバッチ処理を行っているのですが、パフォーマンスが悪く困っています。
その原因となりそうな部分について質問します。

テーブルAに複合索引を作ります。
create unique index uk_A on A(AA,AB,AC,AD);
このテーブルに検索をかけます。そのときにWhere句に書く列の順序は、パフォーマンスには関係ないのでしょうか？
select max(AD) from A where AA=1 and AB=2 and AC=3;
としたときと
select max(AD) from A where AC=3 and AB=2 and AA=1;
としたときの、パフォーマンスの違いです。

このバッチ処理の中で、Aのテーブルに多数のデータを追加するために、コストベースにはできません。また、このSQL文は、プロシージャの中で使用しています。

範囲検索の場合のことは、講習でもあったのですが、等価結合のことは出てきませんでした。

どなたかご存知の方宜しくお願いします。

回答No.2

arata

Oracle7.2とかの時代では、そんなこともあったかもしれませんが、現在は、賢いので、Where句に書いてある順番には、影響されません。

数十万件から、抜いた件数が、かなり多い場合、インデックスがあることが邪魔をすることがあります。
それは、インデックス自体がテーブルである関係上、ほとんどのレコードにヒットしてしまう場合は、インデックスを読む分をプラスするのと、テーブル本体を全件なめるのとでは、後者の方がいいことがあるためです。

また、相手にするレコードが多い場合、必然的にネットワークやミドルウェアが扱うデータ量が増え、Oracle自体の検索スピードより、その部分のボトルネックが影響している場合もありますので、ストアドプロシージャを使って、ＤＢ側で処理するようにすると改善する場合もあります。

お礼

回答ありがとうございます。

>Oracle7.2とかの時代では、そんなこともあったかもしれませんが、現在は、賢いので、Where句に書いてある順番には、影響されません。
CBOでは、順番は関係ないと聞いていたのですが、RBOでも関係ないのですか・・・それは、複合索引だけの話になるのでしょうね。

>数十万件から、抜いた件数が、かなり多い場合、インデックスがあることが邪魔をすることがあります。
そうですね。一応、そのことは検討したのですが、今回の場合は、数十万件中ヒットするのは、最大でも１０件程度なので、BTree索引が効果的だと判断して、普通に索引を作成しました。（カーディナリティは0.01％以下）

>ストアドプロシージャを使って、ＤＢ側で処理するようにすると改善する場合もあります。
質問の中にも書かせていただきましたが、このSQLはプロシージャの中で使用しています。

参考にさせていただきます。

回答No.1

selenity

where AC=3 and AB=2 and AA=1;
なのに、
create unique index uk_A on A(AA,AB,AC,AD);
でいいのですか？
今のWHERE句ならインデックスにADは不要なのでは？

逆にWHERE句にADのパラメータを付加した状態で
試した場合は如何ですか？

補足

>where AC=3 and AB=2 and AA=1;
>なのに、
>create unique index uk_A on A(AA,AB,AC,AD);
>でいいのですか？
そこを質問したいのです。EXPLANを見ると、質問の２つのSQL文両方で、uk_AのRangeScanになっています。ただ、ルールベースでは、Where句は右から評価されると聞いたような気がするので、どちらのほうがいいのかを聞きたいのです。

>今のWHERE句ならインデックスにADは不要なのでは？
そのとおりです。このSQL文だけなら、インデックスにADは必要ありません。変則的な使い方ですが、この一意索引を、主キーの代わりに使っています。そのためにこの一意索引には、必ずADを入れなければならなくなっています。AA、AB、ACだけの索引を作ってもいいのですが、ディスク領域の無駄だと思い、作っていません。ただ、現状により近い状態をお知らせしたかったので、質問と関係ないかもしれませんが、入れさせていただきました。

>逆にWHERE句にADのパラメータを付加した状態で
>試した場合は如何ですか？
SQLの結果として、max(AD)をとっているので、指定するとちょっと結果が変わるような・・・。試してみたほうがよいでしょうか？