• ベストアンサー

Oracleでの検索スピード

redbeanの回答

  • redbean
  • ベストアンサー率38% (130/334)
回答No.2

バージョン8以上のことは分からないのですが、一番始め に考えるのは、やはりインデックスをはることでしょう。 うまくやれば、検索時間を数分の1から数十分の1に縮め ることができます。 RDBに精通した人がやるのが望ましいのですが、原始的 (?)には、速くしたいSQL文のWHERE句にでてくる項目 を、上から順にインデックスのCREATE文に書いてしまえ ばいいでしょう。 あまり多くの項目にインデックスの項目をはると、insert 文が遅くなるかもしれませんが、その時はあまり値の変化 しない項目(例えば「性別」のような)をインデックスか ら外していけばいいと思います。 インデックスの効果があまりないような場合は、専門家に 依頼するのが一番でしょう。 副問い合わせを使いたくなるような複雑な検索では、SQL 文の巧拙によっても検索時間がまったく変わりますが、 書き直すと再テストが必要になってしまいますので、これ は質問の範囲外でしょうね。

mymilky
質問者

お礼

ありがとうございました。 やはりインデックスが有効なのですね。 検討してみます。

関連するQ&A

  • 検索スピードの速い方法を教えてください

    PostgreSQLを使ったJavaシステムで、検索スピードが最も速い方法を教えていただきたいと思います。 ・検索するテーブル(tblS)  scode Varchar 6 主キー  sname Varchar 30  stni Varchar 2  skmk Varchar 2  stnk Int4 ・検索する項目  入力されたnameがテーブルのsnameに存在した場合、他の4項目のデータを読み込む。  これを連続して5回(nameが5件ある)行う。 現在考えているのが、tblSのデータをArrayListに読込み、ArrayListの検索を行う方法です。 現在、tblSの件数は1500件ですが、日々増加しています。 どうかよろしくご教授ください。

  • ファイルメーカ 検索実行せずに該当するレコード数を知りたい

    FM7です。 条件に合致したレコード数を知るために、現在は検索実行をした後に Get(対象レコード数) として求めていますが、検索実行をせずに知ることは出来ますか? テーブルA 顧客-----地区名-----担当者 テーブルB 担当者---顧客数(計算 If テーブルAの担当者 = テーブルBの担当者 then 担当する顧客の数) のような感じになると、ありがたいのですが。

  • SELECTの検索速度と、DB設計

    DB設計で悩んでいます。 ・一つのテーブルにするとカラム数が100ぐらい。 ・格納するデータはテーブルを正規化するようなものではない。 この場合のSELECTでの検索速度ですが、たとえ取り出すカラムを指定していてもカラム数が多いと検索速度に影響がでるのでしょうか? 或いは、テーブルを小分けにして、取り出すデータに応じてテーブルを結合していく方が良いのでしょうか? という感じでカラム数が検索スピードに与える影響についてどなたかご教授いただけませんでしょうか。宜しくお願いします。

    • ベストアンサー
    • MySQL
  • 【ANALYZE】 テーブル・インデックス数が多い

    過去の質問を検索しても該当するものが無かったのでご質問させていただきます。 現在、オプティマイザ(コストベース)について調べています。 ANALYZEコマンドを使用して、テーブルおよびインデックスの 統計情報を取りたいのですが、以下のコマンドのようにテーブル名もしくはインデックス名を指定することしかできないのでしょうか? ANALYZE TABLE テーブル名 COMPUTE STATISTICS; ANALYZE INDEX インデックス名 COMPUTE STATISTICS; テーブル数及びインデックス数が非常に多いため、上記の方法では手間がかかります。 もう少し効率の良い方法を探しているのですが、ご存知であれば教えてください。 よろしくお願いいたします。

  • select count(*) の性能

    業務アプリケーションで次のSQL文を実行すると非常に時間がかかっています。 "select count(*) from テーブル名 where カラムA='値B'" このテーブルは200万件以上のレコードが存在していて、カラムAには索引が作成されています。DBのOPTIMIZERの処理を見ると(1)索引検索をした後で(2)対象レコードのROWIDを取得して(3)その後FETCH処理をしているのですが、(3)のFETCHの処理が非常に時間がかかっています。どうしたらこの検索を早くできるかヒントがあれば教えて下さい。私のしろうと考えでいくと、DBがどうして(3)のFETCHの処理をしているのかもわかりません。よろしくお願いします。

  • 大量のレコードの中からデータ抽出する際にその抽出スピードを高速化させる方法は?

    2004年9月8日こんにちは。 W2K/Access2Kを使用しています。 現在数百程度のレコード数をもつDBで、 検索・抽出作業(データ型が“メモ型”フィールドの中からのデータ抽出が主)を頻繁に行っています。 その抽出スピードは、今の所は気にならない程度ですが、将来そのデータ・レコード数が数万から数十万まで拡大した時のスピードの劣化が心配です。 そこで質問ですが、 1. スピードの劣化を最小限に留めるための一般的なDB構造上の工夫。 2. データのテーブルを独立Data Base“dbB”として、元々のData Base“dbA”と切り離し、dbBをdbAの参照用DBとしてのみ使う、という方法を聞きました。 この方法について、上記の目的(抽出スピードを上げる)にはどの程度効果的でしょうか?  できればその具体的な方法を教えて頂けますと喜びます。以上宜しくお願いします。

  • FILEMAKER6の重複するレコードの検索について。

    現在数万件のレコードを扱っていますが、自己連結リレーションを使用して計算フィールドで重複するレコードを割り出し、そのフィールドで検索をかけると索引設定ができないため検索に時間がかかってしまいます。 これ以外の方法で処理に時間をかけずに重複するレコードを特定する方法があれば是非教えてください。よろしくお願いします。

  • Oracleの追加した索引を利用しているのか確認。

    こんにちは。 Oracleの調整を行っています。 テーブルに対して索引を追加して、実行速度の改善を図ろうとしていますが、追加された索引がSQL文発行後に、正しく利用されているのかを確認したいと思っています。 暫く触っていなかったので、記憶だけですがDBA Studioにて確認できたと思って探していますが見当たりません。 別の方法での確認方法でも構いませんので、ご存知の方教えて頂けないでしょうか。 Oracle8iです。宜しくお願い致します。

  • oracleのSQLパフォーマンスについて

    oracleのSQLパフォーマンスについて質問です。 当方、SQLは初めてで、ずぶの素人ですが、SQLパフォーマンスを改善することになりました。 質問の仕方も悪いとは思いますが、お力添えをいただきたいと思います。 【質問1】 DBのレコード件数は、SQLパフォーマンスにどう影響するでしょうか?以下例のようなことが知りたいです。 例1 INDEXのないテーブルに対しSQLを発行する場合、レコード件数の多いDBとレコード件数の少ないDBでは、レコード件数が少ない方が、パフォーマンスが良い? (前提として、検索対象DBは、レコード件数以外に差がないとする) 例2 WHERE句にINDEX項目を使用した場合、DBのレコード件数はパフォーマンスに影響しない (前提として、アクセスパスは適切で、検索対象をうまく絞り込むことができる) 例3 WHERE句にINDEX項目を使用したSQLをレコード件数の多いDBに発行する場合と、WHERE句にINDEX項目がないSQLをレコード件数の少ないDBに発行する場合では、どちらがパフォーマンスがよいのか (前提として検索対象DBは、レコード件数以外に差がないとする) 【質問2】 INDEXをDBに追加すると、INSERT、UPDATE、DELETEの際に、どのくらい影響するのでしょうか? 対象のDBは、5項目あり、400万件くらいのレコードがあります。また、複合項目(2項目)のプライマリキーと、単一INDEXがついており、新たに3項目の複合INDEXを追加しようとしています。 以上、よろしくお願いいたします。

  • Accessで検索を高速化

    顧客データの検索画面をAccessで作成しています。 テーブルの数は全部で9、各テーブルのレコード数は約1万、 各テーブルのフィールド数は多くて20くらいです。 テーブル用のAccessをサーバに置いておいて、 検索画面フォームのAccessはそれぞれの社員のローカルに置いています。 テーブルを参照している社員数は20弱です。 Accessのバージョンは2007や2010、Runtimeを使っている社員もいます。 氏名フリガナと電話番号で検索できるようになっていて、 下の□のなかに、各テーブルの該当のものが抽出されるようになっています。 この検索画面の動きが最近著しく悪いです。 もっとサクサク動くようにしたいです。 色々調べてはみたのですが ・テーブルをSQLサーバに置いてリンクしなおしてみたのですが 余計動きが遅くなりました。 ・「ある程度絞り込んでから検索をかける」というのが高速化のポイントらしいですが 常に全件が検索対象なので、それができません。 ・テーブルのレコードについては常に全社員が新規作成、変更等できる状態でなければならないです。 動きを高速化させる知恵はないでしょうか? ご教授ください!