11.1. 序文

次のようなテーブルを考えてみましょう。

CREATE TABLE test1 (
    id integer,
    content varchar
);

アプリケーションで次の形の多くの問い合わせが必要としています。

SELECT content FROM test1 WHERE id = constant;

高度な準備を行なっていなければ、システムで一致する項目をすべて検出するためには通常、test1テーブル全体を1行毎にスキャンする必要があります。 test1に多くの行があり、その問い合わせで返されるのが数行(おそらく0行か1行)しかない場合、これは明らかに効率が悪い方法といえます。 システムがインデックスをid列上に保持するよう設定してあれば、一致する行を検出するのにより効率のよい方法を使うことができます。 たとえば、検索ツリーを数層分検索するだけで済む可能性もあります。

ほとんどのノンフィクションの本で、同じような手法が使われています。 読者が頻繁に調べる用語および概念は、その本の最後にアルファベット順に索引としてまとめられています。 その本に興味を持った読者は、索引（インデックス）を調べ、比較的速く簡単に該当するページを開くことができるため、見たい場所を探すために本全部を読む必要はありません。 読者がよく調べそうな項目を予想するのが著者の仕事であるように、どのインデックスが有益であるかを予測するのはデータベースプログラマの仕事です。

上述のようにid列にインデックスを作成する場合は、以下のようなコマンドを使用します。

CREATE INDEX test1_id_index ON test1 (id);

インデックス名test1_id_indexには、何を選んでも構いませんが、そのインデックスを何のために作成したかを後で思い出せるような名前を選ぶべきです。

インデックスを削除するには、DROP INDEXコマンドを使用します。 テーブルのインデックスは、いつでも追加および削除できます。

いったんインデックスを作成すれば、それ以上の処理は必要はありません。 システムは、テーブルが更新される時インデックスを更新します。 また、テーブルの逐次スキャンよりも効率的であると判断された場合に、インデックスが使用されます。 しかし、問い合わせプランナで情報に基づいた判断をするためには、定期的にANALYZEコマンドを実行し、統計情報を更新する必要があります。 インデックスが使われているかどうか、およびプランナがインデックスを使わないと判断した状況および理由を調べる方法については、第13章を参照してください。

インデックスにより、UPDATEやDELETEコマンドの検索条件でも使用できます。 インデックスは、結合問い合わせでより多く使用されます。 したがって、結合条件で記述されている列にインデックスを定義すれば、結合を伴った問い合わせにかかる時間をかなり短縮できます。

インデックスが作成された場合、システムでは、テーブルとインデックスとの間で常に同期を取っておく必要があります。 これにより、データ操作の処理にオーバーヘッドが加わります。 したがって、重要でないインデックスや、全く使用されなくなったインデックスは、削除しておいた方がよいでしょう。 また、問い合わせやデータ操作のコマンドでは、1つのテーブルに対して最大1つのインデックスのみ使用可能であることに注意して下さい。