• 締切済み

INDEX RANGE SCAN とは?

OracleのINDEX RANGE SCANについての質問です。 私の理解のレベルでは、INDEX RANGE SCANは範囲検索をする時に発生し、 それ自体は効率的にインデックスを利用している状態である、と理解しています。 もっといえば、betweenを使用したり演算子に「>=」などの不等号を使用した とき以外には発生しないはずと思っていました。 しかし先日、条件部分に「=」等号しかないSQLにてINDEX RANGE SCANが発生しました。 INDEX SKIP SCAN ならまだ話はわかるのですが、間違いなくINDEX RANGE SCANでした。 範囲検索で無い場合にINDEX RANGE SCANになる意味がよくわかりません。 ■以下質問です。 範囲検索の場合にINDEX RANGE SCANになるという私の認識はあっているか。 どのような場合に、等価条件だけの場合にINDEX RANGE SCANになるのか。 等価条件だけなのにINDEX RANGE SCANになる場合、検索の仕組みについて。 ■参考情報として記述しておきます。 バージョンは9iです。 1つのテーブルに対するSELECT文で where句には4つのカラムが等価条件で指定されています。 これらのカラムは条件・カラムの値ともにNULLではありません。 関係あるかわかりませんが、カーディナリティが高いにもかかわらず 適切なインデックスが無いSQLでした。 よろしくお願いします。

  • Oracle
  • 回答数2
  • ありがとう数3

みんなの回答

  • utakataXEX
  • ベストアンサー率69% (711/1018)
回答No.2

>特に >>先頭の列だけ検索条件を指定した場合 > >この場合になぜINDEX RANGE SCANになってしまうのでしょうか? A |B |C --------- 0001|01|0 0002|01|1 0002|02|1 0003|02|1 0004|02|0 0004|03|0 ・ ・ ・ こんなような感じですよね。 で、アナライズしてあるものと仮定して、 select * from テーブル where A = バインド変数1 and B = バインド変数2 and C = バインド変数3 のようなSQLを実行した場合、カラムA自体はカーディナリティが高いと 言っても、ユニークインデックスではないのですから、オプティマイザが INDEX RANGE SCANを選択するのは自然です。 その値がたまたまユニークになっていてもユニークインデックス でなければRANGE SCANになります。 A, Bの複合インデックスがユニークインデックスなら INDEX UNIQUE SCAN になると思います。

mibusys
質問者

お礼

なんとなくですが理解できました。 ありがとうございました。

mibusys
質問者

補足

>のようなSQLを実行した場合、カラムA自体はカーディナリティが高いと >言っても、ユニークインデックスではないのですから、オプティマイザが >INDEX RANGE SCANを選択するのは自然です。 これを改めて読んでようやくわかったかもしれないので確認させてください。 ユニークインデックスでは無い場合には必ずINDEX RANGE SCANになるのでしょうか?

回答No.1

複数列でインデクスが構成されている状態で、先頭の列だけ検索条件を指定した場合とか、いろいろあると思いますよ。 インデクス定義や検索条件を具体的に示してもらえれば、もう少し具体的なアドバイスができると思います。

mibusys
質問者

お礼

ありがとうございました。

mibusys
質問者

補足

最初の情報にいくつか間違いがありました。 情報の修正・追記しておきます。 テーブルに対してカラムは10ほどあります。 検索条件に指定していたのは3つのカラムでした(A, B, C)。 カラムAは種類が1000ほどあるカラムです。 カラムBは種類が11しかないカラムです。 カラムCは論理削除のカラムで、値は0, 1しか入らない すなわちカーディナリティ非常に低いカラムです。 A, B 2つを指定する複合インデックスが存在します。 すなわち、非常に適切に思えるインデックスが存在していました。 >複数列でインデクスが構成されている状態で、 >先頭の列だけ検索条件を指定した場合とか、いろいろあると思いますよ。 単独カラムのインデックスの場合には絶対に生じないということでしょうか? 複合インデックスの場合には生じえるのですか? 特に >先頭の列だけ検索条件を指定した場合 この場合になぜINDEX RANGE SCANになってしまうのでしょうか? この点がまさに私の知りたい点だと思います。 この点についてご説明お願いしたいです。よろしくお願いします。

関連するQ&A

  • インデックスについて

    宜しくお願いします。 MySQLで検索速度を上げる為にカラム毎に設定するINDEXですが、 fulltextとindexの2種を使えば、全カラムにINDEXを付けられると思いますが、検索するか分からないカラムにもINDEXをつけた場合、何か不都合がおこりますか? 例えば、INDEXが多すぎると逆に検索が遅くなるなどです。 ちなみに、fulltextは日本語に対応していないのは理解しております。

    • ベストアンサー
    • MySQL
  • インデックスを張るべき項目について

    20万件レコードのあるテーブルに、インデックスを張ると INSERTが遅くなるので、WHERE句で検索する項目のどれに インデックスを張るか悩んでいます。 インデックスはパターンが多い程、張った場合に 検索速度が向上すると理解しているのですが正しいでしょうか? であれば、下記1.だけは貼ろうと思っているのですが・・ 1.カラムに入るデータが殆どバラバラのVARCHAR(30) 2.カラムに入るデータは10万パターンのINT型 3.カラムに入るデータは1万パターンのINT型 4.カラムに入るデータはdatetime型 インデックスを張る事でINSERT速度が何%ぐらい下がるでしょうか? よろしくお願いします。

    • ベストアンサー
    • MySQL
  • インデックスとLIKE演算

    MySQLを勉強中です。 バージョン:5.x(詳しくはわかりません) エンジン:InnoDB インデックスを指定したカラムに対してLIKE演算"%検索文字%"を実行するとシーケンシャルに検索を行うと聞きましたが、何か回避する方法等はありませんでしょうか? ※インデックスを指定したカラムの型はchar(255)で、日本語(UTF-8)も含まれます。

    • ベストアンサー
    • MySQL
  • INDEXの仕様

    PostgreSQL8.1.1(RedHatLinux)にて テーブルのtext列に対してindexを作成しました。 作成した列に対して、LIKE検索を行っております。 しかし、「EXPLAIN」を利用してSQLの実行計画を見たんですが、 「Seq Scan」からしか始まらず、 「Index Scan」という文字が見当たりません。 PostgreSQLにてindexを張った列に対するLIKE検索では、 indexは使用されないのでしょうか?

  • いつもお世話になってます。

    いつもお世話になってます。 他プロジェクトのまた聞きなのですが。。。。 oracle9iからoracle10gにバージョンアップを行いました。 数日後、数千万件にバインド変数でアクセスするSQLがインデックスを使用せず、フルアクセスしてしまい、トラブルとなりました。 この事象はCBOのデメリットなので、納得なのですが。 1.トラブル発生前は該当SQLはINDEX RANGE SCANを使用していた。 2.トラブル対処として、ヒント句を使用すると、INDEX FULL SCANになってしまい、結果として遅くなってしまった。 前置きが長くなりましたが、ヒント句を使用してINDEX FULL SCANになってしまった場合、明示的にINDEX RANGE SCANを適用させる方法はあるのでしょうか? ネット検索してもそのような方法を見つけることができませんでした。

  • 複数のインデックスについて

    以下のようなテーブルで、 ------------------------- テーブル名:hoge カラム1:name(名前) カラム2:age(年齢) カラム3:job(職業) INDEX age(age) ------------------------- 今現在、年齢で検索することが多いため、ageにIndexを張っているのですが、職業でも検索したいと思っています。 (今現在、職業で検索するとIndexが関係ないためか低速です。) この場合、「ALTER TABLE hoge ADD INDEX job(job)」で大丈夫でしょうか? インデックスが良くわかってないのですが、こうすると、今の年齢用のインデックスとは、全く別のインデックスが作成されると思って良いのでしょうか? (年齢のインデックスの下に職業のインデックスが作成され、職業で検索しても、結局、年齢のインデックスをまたぐため低速になる、なんてことは無いのでしょうか?) よろしくお願いします。

    • ベストアンサー
    • MySQL
  • 複合インデックスの設定に関して

    MySQLの複合インデックスに関して質問させて頂きます。 現在検索条件に3つのカラムを使用して検索をかけているSELECT文があります。 データの件数は100万件ほどあるとします。 【例】 「SELECT * FROM test WHERE a = '1' AND b = 'xxxxx' AND c = '1';」 カラム「a」「c」は、0と1のみが格納されたカラムで、頻繁に更新されます。 カラム「b」は、同じ値が入ることがありますが、ほぼユニークな文字列が格納されます。 上記のような場合、インデックスは ・「a,b,c」の全てを設定した複合インデックスを作成するべきか。 ・cは頻繁に更新されるので、「a,b」のみの複合インデックスを作成するべきか。 ・aも同じく頻繁に更新されるので、WHERE句の検索順をbを先に持ってきて、「b」のみの単独インデックスを作成するべきか。 一概にこうだという答えは無いかもしれませんが、何か良い方法があれば教えて頂けると幸いです。 また、質問に不備な点がございましたら、ご指摘お願いいたします。

    • ベストアンサー
    • MySQL
  • MySQL マルチカラムインデックスでの範囲検索

    InnoDBでマルチカラムインデックスをもつテーブルに対して、1つ目のキーに範囲検索を行った場合、2つ目のキーはどんな場合も使われないのでしょうか? ■前提 ・テーブル名  tbl ・カラム  kaypert1(DATETIME) ,keypart2(INTEGER) ・インデックス  kaypert1,keypart2 このテーブルに対し、  SELECT * FROM bl WHERE keypart1 < '2009-03-31 20:00:00' AND keypart2 = 3; とした場合。 自分のイメージとしては、この検索でB-Treeの形としてkeypart1であてはまったデータそれぞれの下のTree(keypart2)を見に行くのかなと思っていました。 ただ、「LinuxDBシステム構築運用入門」という本を見ると、マルチカラムインデックスをもつテーブルに対して、1つ目のキーに範囲検索を行った場合は2つ目以降のキーは全く使われないと書いてあったので確認をしたいです。

  • date型のインデックス

    インデックスが貼ってあるdate型のカラムがあるのですが、うまくインデックスがあたりません。 検索条件を下記のようにしています。 working_date = TO_DATE('2010/11/26') date型は秒数を保持していることが影響しているのでしょうか? ファンクションインデックスを貼って、下記のようにすればインデックスは当たってます。  TO_DATE(working_date,'YYYY/MM/DD') = '2010/11/26' ご存知のかたがおられましたら教えてください。

  • コンポジット一意インデックスとは?

    趣味でPHPとMYSQLをいじってる大学生です。 先日はこちらで助けて頂いてとても助かりました。 ご返答いただきました皆様ありがとうございました。 単発の質問で申し訳ないのですが インデックスの指定をする際に疑問点がでてきたので 質問させて下さい。 タイトルにもあげたのですが、 コンポジット一意インデックスというのは インデックス(インデックスの名前はkeyの値) で複数カラムにインデックス指定するということだと思いますが 一意はユニークというのは 任意の挿入されるレコードは、2つの場合に限定すると 2のカラムを見ると他のレコードとかぶらないというか 要するに2つのフィールドをあわせて考えて、 ユニークであるという理解でよいでしょうか? 言葉がおもいつきませんが 例えば宝くじの  組  番号 購入者 ...etc  A組 0001 B組 0001 A組 0023 C組 ・・・ のようなデータを扱う際に 組と番号にコンポジット一意インデックスを割り振るといいというという理解でいいでしょうか? その理解が正しいか間違っているか? 教えていただけると幸いです。 そして、この理解で正しいのならば もしも 番号=0002 など、2つのフィールドのうち1つで検索した場合だとインデックスは役割を果たすのでしょうか? コンポじゃないと機能しないのか?ということです。 コンポじゃないと機能しないのであれば3つのインデックス つまり、(組,番号[コンポ]),(組),(番号) を作成するのが正しいのでしょうか? よろしくお願い致します。