select count(*) の性能

質問

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

回答No.4

bin-chan

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

ＷｉｎｄｏｗｓＮＴでは「ＮＴＦＳのデフラグは不要だ！」といってたのに
２０００にはしっかり機能が実装されてるぐらいなので。

お礼

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

回答No.3

redbean

count(*) の代りに count(カラムA) とでもすれば、
速くなるでしょう。

お礼

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

回答No.2

bin-chan

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

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

なお、索引がついていても、頻繁にレコードの追加・削除が行われるのなら
いっぺん再編成してみるのも良いでしょう。
（ＥＸＰＯＲＴ＆ＩＭＰＯＲＴ、ＤＲＯＰ＆ＣｒｅａｔｅＩｎｄｅｘ）

お礼

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

回答No.1

bin-chan

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

where句つけずに全件の方が速いでしょ？