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

このQ&Aに関連する最新のQ&A

A 回答 (4件)

> テストのつど実施するようにしております。


「表領域の離散」は影響しませんか?

WindowsNTでは「NTFSのデフラグは不要だ!」といってたのに
2000にはしっかり機能が実装されてるぐらいなので。
    • good
    • 0
この回答へのお礼

ありがとうございます。結果的に問題は解決しました。私の説明不足だったのですが、実はwhere句で条件指定しているカラムがもう一つありまして、別々のインデックスだったのを一つの複合インデックスにしたら劇的に早くなりました。いろいろとありがとうございました。

お礼日時:2001/09/19 09:11

count(*) の代りに count(カラムA) とでもすれば、


速くなるでしょう。
    • good
    • 0
この回答へのお礼

ありがとうございます。結果的に問題は解決しました。私の説明不足だったのですが、実はwhere句で条件指定しているカラムがもう一つありまして、別々のインデックスだったのを一つの複合インデックスにしたら劇的に早くなりました。

お礼日時:2001/09/19 09:09

あーーごめんなさい。

索引ついてるんですね。失礼しました。

ちなみに200万件に対して「値」は何種類ぐらいでしょうか?
OracleならBITMAPインデックスを検討するのが良いかも?
全件に対して0.01%以下の件数ならメリットがあるはず。

なお、索引がついていても、頻繁にレコードの追加・削除が行われるのなら
いっぺん再編成してみるのも良いでしょう。
(EXPORT&IMPORT、DROP&CreateIndex)
    • good
    • 0
この回答へのお礼

アドバイスありがとうございます。索引の「値」の種類は600種類程です。UDBなのでビットマップ索引はオプティマイザーが必要だと判断した時に処理の中で一時的に作成されて明示的には作成できません。
ちなみにoracleで言うところの索引構成表を作成したりもしましたが、時間がかかっている部分は索引検索の部分ではなくてFETCHの部分なので、特にパフォーマンス上のメリットも得られませんでした。
補足いたしますと当テーブル上ではテスト環境にあり、テーブルの再作成と統計表のREFRESHはテストのつど実施するようにしております。

お礼日時:2001/09/18 01:52

カラムAに索引をつけることが最も重要と思います。



where句つけずに全件の方が速いでしょ?
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!


人気Q&Aランキング