7.1. 序文

インデックスの必要性を示す古典的な例は、下記のようなテーブルです。

CREATE TABLE test1 (
    id integer,
    content varchar
);

このアプリケーションは以下のような沢山の問い合わせを必要とします。

SELECT content FROM test1 WHERE id = constant;

普通は、システムは全てのあてはまる項目を見つけるためにtest1 テーブルを１行ごとにスキャンしなければいけません。もし test1に沢山の行があり問い合わせが数行 (おそらくゼロか 1 行)しか返さない場合、それは明かに効率が悪いメソッド です。もしシステムがインデックスをidカラム 上に保ち続けるよう指示されていれば、あてはまる行をみつけるのに もっと効率の良いメソッドを使うことができます。例えば、検索ツリーの 中で数層しか進まなくて良いかもしれません。

ほとんどのノンフィクションの本では似たようなアプローチが使われています。 読者が頻繁に調べる用語と概念は本の終りにアルファベット順にまとめられて います。興味を持った読者はインデックスを比較的速くスキャンし見たい ページにとぶことができるため、見たい場所を探すために本全部を読む 必要がありません。読者が調べる可能性の高い単語を予測するのが著者の 仕事であるように、どのインデックスが有益であるかを予測するのは データベースプログラマの仕事です。

idカラム上にインデックスを作るために下記の ようなコマンドが使われます。

CREATE INDEX test1_id_index ON test1 (id);

test1_id_indexという名前は自由に選択されることが できますが、あとでそのインデックスが何のためだったか思い出せる ものを選ぶことが必要です。

インデックスを削除するためにはDROP INDEXコマンド を使って下さい。インデックスはいつでもテーブルに追加したり削除することが できます。

一度インデックスが作られると、それ以上の干渉は必要ありません。 システムは、順テーブルスキャンよりも効率が上がると思われる場合に インデックスを使うのです。しかし、問い合わせプランナが根拠のある決断 を下すことを許すために、定期的にVACUUM ANALYZE を実行する必要があります。更に、インデックスが使われているかどうか、 いつそしてなぜプランナがインデックスをつかわない ことを選択したかを知るためにはChapter 11 を読んで下さい。

インデックスはUPDATEや DELETEの 検索条件の利益にもなります。問い合わせやデータを扱うコマンドは 最大でもテーブル毎に一つのインデックスしか使えないことに注意して ください。インデックスはテーブル結合メソッドでも使うことができます。 したがって、結合条件の一部である、カラム上で定義されたインデックス は結合を使った問い合わせを著しく速めることができます。

インデックスが作られると、テーブルと一致するように保たれなくては いけません。これはデータを扱う演算にオーバーヘッドを加えます。 したがって、重要ではないインデックスや全く使われないインデックス は削除されるべきです。