インデックスの張り方について

質問

とあるテーブルのレコード数は、全部で２８レコードあります。
このテーブルにはインデックスを張っておらず、シーケンシャルスキャンでDBよりSELECTしています。
通常にシステムを運用する上では問題ないのですが、負荷試験などで同時接続数を50などにしループでDBにアクセスさせるとき、その他の4000万レコード程度あるテーブルをSELECTしてくるのは0.00xxx秒で行えるのに対し、この28レコードしかないテーブルからSELECTしてくる際は、遅い場合で0.xx秒もかかってしまいます。
この２８レコードしかないテーブルにインデックスを張っても、レコード数が少なすぎてまったく意味がありませんでした。
ちなみにこのレコードへは下記のようなSELECT文を発行しています

SELECT xxx,xxx,xxx FROM xxxx where カラム1 = aaaa AND カラム2 IN (bbb,ccc) AND カラム3 = ddd;

このレコードのSELECT文を高速化させるには、どのような手段があるでしょうか。
お手数ですがご教示いただけますと幸いでございます。

DBはPostgreSQL、PHPのWebアプリケーションよりDBにアクセスしています。

回答No.2

alte_6 · ベストアンサー

（遅い場合で0.xx秒）が遅いのかどうかは不明ですが・・

4000万レコード程度あるテーブルのクエリーが0.00xxx秒というのは
どういうSQLでしょうか
またどうやって測ったのでしょうか？EXPLAIN ANALYZEでしょうか？

28件のTABLEへはどういったインデックスを張ったのでしょうか？
条件にある主キーカラムにインデックスを張っていますでしょうか。
主キーカラム以外の条件を取り除くか、もしくはすべての条件カラムを含む
複合索引を張って検索を行ってみてはどうでしょうか。＾＾

＃EXPLAINでカラム2のIN関数でインデックスを使用しない事があれば
＃(カラム2=bbb OR カラム2=ccc)に置き換えてしてみて下さい。

お礼

EXPLAIN ANALYZEでも図りましたし、実際運用していて、どのSQLにどれくらいのセレクト時間がかかるか、すべてログに残していて、それを見て発見いたしました。

条件にある主キーカラムにインデックスを張ってみましたが、やはり変わりありませんでした。。
複合索引を張ってみましたが、それも効果はないようです、、、

もう少し考えて見ます、ありがとうございました。

回答No.1

t-okura

とあるテーブルを vacuum FULL してもだめでしょうか。

お礼

一応、全テーブル毎日vacuumしているため、このテーブルもバキューム対象です。。
念のためもう一度してみましたが、効果はありませんでした。