- ベストアンサー
ORACLEのインデックスについて
現在、ORACLE9を使用しているのですが INDEXについて理解できないことがあったので 教えてください。 組織、社員という2つしか項目を持たない 従業員という表があり600件ほどのデータがあります。 変更前は、 ・組織、社員にユニークインデックスは作成されていた。 ・600件ほどのデータの組織は全て同一。 となっており、その状態で select * from 従業員 where 組織 = 'ALL' and 社員 = '001' を流すとFULL SCANになっていました。 FULL SCANを回避できないかと思い、社員のみのインデックスを 追加し(* 一番下にインデックス追加時のSQLをはっています) select * from 従業員 where 組織 = 'ALL' and 社員 = '001' を流すと追加したインデックスを読んでいました。 既に作成されていたユニークインデックスと異なるインデックスが 追加されたのかと思い、DBA_INDEXESの中を確認しましたが 異なっているのは、 ・UNIQUENESS ・INITIAL_EXTENT(ユニークインデックスは24576、 追加したインデックスは40960) ・LEAF_BLOCKS(ユニークインデックスは3、 追加したインデックスは2) の3点のみでした。 なぜこのような動きになるか理解できず、今後の対応に 迷っています。 ・原因 ・調査したらいい場所 ・参考資料 などがありましたら教えてください。 よろしくお願いします。 (*) インデックス追加時のSQL文は、create index 従業員A on 従業員 (社員) tablespace index storage (initial 40000 next 100000 maxextents unlimited pctincrease 0) pctfree 10となっています。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
組織+社員の複合キーで、最初の項目組織は"ALL"のみということで、カーディナリティーが低いというか一つですよね。 このパターン(カーディナリティが低い)だとOracleのオプティマイザーは全表スキャンに走るのだと思います。
その他の回答 (2)
- k_o_r_o_c_h_a_n
- ベストアンサー率55% (526/942)
全表検索なのか索引検索なのか、といった実行計画については、 オプティマイザが決めます。 オプティマイザは、大きく2つ(RBO/CBO)に分けられますが、CBOに関しては 索引があるから、”索引を使おう”という単純な判断をしません。 データの分布やデータ量などの統計情報を基に、効率的と思えば、 全表検索を行います。 たぶん、CBOをお使いかと思いますが、まずは、統計情報を更新してみて それでも、オラクルが全表検索し、かつ、索引を使った方が良いのであれば、 オプティマイザヒントで、索引の使用を強要するのが良いと思います。 (本質的に、社員だけの索引が必要ないのであれば削除する) select /*+ index(従業員 索引名) */ * from 従業員 where ~;
補足
回答ありがとうございます。 オプティマイザはCBOです。 単文であればヒント文の使用もできるのですが、 select * from 支払先 a , 従業員 b where a.組織=b.組織 and a.支払先番号 = b.社員 and a.支払先番号 = 1 のようにジョインして使用している時も、インデックスを 追加しない場合は従業員テーブルについてFULL SCANしている 状態です。 それで既に存在しているインデックスと大して変わらない 社員のみのインデックスを追加しようかとも考えているのですが、 大して変わらないだけに躊躇しています。 また、同様のケースが複数のテーブルに関して確認されており 「大して変わらなくてもどんどんインデックスを作る」 という方針をとるかとらないかで迷っています。 LEAF_BLOCKSなどをいじるだけで読むようになれば一番いいん ですけどね。
その2つの列に入っているデータの種類が少ないのではないのでしょうか?種類が少ないとインデックスを使わないと聞いたことがあります。
補足
回答ありがとうございます。 組織は一種類しかありませんが、社員は全て異なる値に なっています。 だからユニークインデックスだけでインデックスよんで いい気がするんですが。。。
お礼
回答ありがとうございます。 カーディナリティ、という言葉から少し調べたところ 新しいことも分かりました。 感謝です。 パッケージソフトをカスタマイズして納入しており こういったケースがいくつかあるので、監視を続けながら インデックスの追加を検討していこうと思います。