• 締切
  • すぐに回答を!

select count(*) の性能

  • 質問No.137124
  • 閲覧数1898
  • ありがとう数3
  • 気になる数0
  • 回答数4
  • コメント数0

お礼率 75% (3/4)

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

回答 (全4件)

  • 回答No.4

ベストアンサー率 33% (1403/4213)

> テストのつど実施するようにしております。
「表領域の離散」は影響しませんか?

WindowsNTでは「NTFSのデフラグは不要だ!」といってたのに
2000にはしっかり機能が実装されてるぐらいなので。
お礼コメント
satuki5

お礼率 75% (3/4)

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

ベストアンサー率 38% (130/334)

count(*) の代りに count(カラムA) とでもすれば、
速くなるでしょう。
お礼コメント
satuki5

お礼率 75% (3/4)

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

ベストアンサー率 33% (1403/4213)

あーーごめんなさい。索引ついてるんですね。失礼しました。

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

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

お礼率 75% (3/4)

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

ベストアンサー率 33% (1403/4213)

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

where句つけずに全件の方が速いでしょ?
結果を報告する
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。
AIエージェント「あい」

こんにちは。AIエージェントの「あい」です。
あなたの悩みに、OKWAVE 3,600万件のQ&Aを分析して最適な回答をご提案します。

関連するQ&A

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

ピックアップ

ページ先頭へ