リレーショナルデータベースのテーブル設計を行っていると、どのカラムにインデックスをつければよいかがよくわからなくなってしまうのは私だけではないと思います。
DBMSがMySQLやPostgreSQLの場合、私はEXPLAIN句を使ってインデックスのつけ忘れがないかをチェックするようにしています。
EXPLAIN句を使うとSELECTクエリの実行計画が表示されるようになり、この情報を元にテーブルのインデックスを設定していきます。
MySQLの場合
EXPLAIN SELECT ...
を実行すると表示されるテーブルのうち、チェックすべきカラムは「type」です。
このtypeカラムに「ALL」と表示されているレコードがあれば、そのテーブルのインデックスを見直す必要があるかもしれません。
PostgreSQLの場合
EXPLAIN SELECT ...
を実行すると表示される「QUERY PLAN」に「Seq Scan on」から始まる行がある場合、onの後に続くテーブルのインデックスを見直す必要があるかもしれません。
(注意)
テーブルのインデックスは万能ではないので、何でもつけていればよいというわけではありません。
インデックスをつけすぎると更新性能が低下してしまいます。
またデータの種類によってはインデックスをつけても検索速度の向上が見込めない場合があります。
その最たる例はブーリアン値や性別のような限られた少ない種類のデータしか格納されないカラムです。
DBMSによっては、こういったデータ用のインデックス技術が実装されているようですが…。
参考:
PostgreSQL 文書
MySQL 4.1 リファレンスマニュアル
DBMSがMySQLやPostgreSQLの場合、私はEXPLAIN句を使ってインデックスのつけ忘れがないかをチェックするようにしています。
EXPLAIN句を使うとSELECTクエリの実行計画が表示されるようになり、この情報を元にテーブルのインデックスを設定していきます。
MySQLの場合
EXPLAIN SELECT ...
を実行すると表示されるテーブルのうち、チェックすべきカラムは「type」です。
このtypeカラムに「ALL」と表示されているレコードがあれば、そのテーブルのインデックスを見直す必要があるかもしれません。
PostgreSQLの場合
EXPLAIN SELECT ...
を実行すると表示される「QUERY PLAN」に「Seq Scan on」から始まる行がある場合、onの後に続くテーブルのインデックスを見直す必要があるかもしれません。
(注意)
テーブルのインデックスは万能ではないので、何でもつけていればよいというわけではありません。
インデックスをつけすぎると更新性能が低下してしまいます。
またデータの種類によってはインデックスをつけても検索速度の向上が見込めない場合があります。
その最たる例はブーリアン値や性別のような限られた少ない種類のデータしか格納されないカラムです。
DBMSによっては、こういったデータ用のインデックス技術が実装されているようですが…。
参考:
PostgreSQL 文書
MySQL 4.1 リファレンスマニュアル