-PR-
締切り
済み

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

  • 暇なときにでも
  • 質問No.38087
  • 閲覧数344
  • ありがとう数8
  • 気になる数0
  • 回答数2
  • コメント数0

お礼率 51% (32/62)

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

テーブル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文は、プロシージャの中で使用しています。

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

どなたかご存知の方宜しくお願いします。
通報する
  • 回答数2
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

回答 (全2件)

  • 回答No.1
レベル12

ベストアンサー率 41% (324/772)

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);
でいいのですか?
今のWHERE句ならインデックスにADは不要なのでは?

逆にWHERE句にADのパラメータを付加した状態で
試した場合は如何ですか?
補足コメント
msystem

お礼率 51% (32/62)

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

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

>逆にWHERE句にADのパラメータを付加した状態で
>試した場合は如何ですか?
SQLの結果として、max(AD)をとっているので、指定するとちょっと結果が変わるような・・・。試してみたほうがよいでしょうか?
投稿日時 - 2001-02-08 17:35:48


  • 回答No.2
レベル11

ベストアンサー率 49% (139/279)

Oracle7.2とかの時代では、そんなこともあったかもしれませんが、現在は、賢いので、Where句に書いてある順番には、影響されません。 数十万件から、抜いた件数が、かなり多い場合、インデックスがあることが邪魔をすることがあります。 それは、インデックス自体がテーブルである関係上、ほとんどのレコードにヒットしてしまう場合は、インデックスを読む分をプラスするのと、テーブル本体を全件なめるのとでは、 ...続きを読む
Oracle7.2とかの時代では、そんなこともあったかもしれませんが、現在は、賢いので、Where句に書いてある順番には、影響されません。

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

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

お礼率 51% (32/62)

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

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

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

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

参考にさせていただきます。
投稿日時 - 2001-02-09 08:18:10
このQ&Aで解決しましたか?
関連するQ&A
-PR-
-PR-
このQ&Aにこう思った!同じようなことあった!感想や体験を書こう
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-
-PR-
-PR-

特集


関連するQ&A

-PR-

ピックアップ

-PR-
ページ先頭へ