7.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をして統計情報を更新する必要があります。さらに、インデックスが使われているかどうか、いつそしてなぜプランナがインデックスを使わない ことを選択したかを知るためにはChapter 11を読んでください。

インデックスは、UPDATEやDELETEの検索条件にも便利です。また、テーブル結合でも使うことができます。したがって、結合条件の一部である列にインデックスが定義されている場合は、結合を伴った問い合わせの速度を著しく速めることができます。

インデックスが作成されると、システムはテーブルとインデックスの同期を維持する必要があります。これは、データ操作を行なう際にオーバーヘッドを加えます。したがって、重要ではないインデックスや、全く使用しないインデックスは削除されるべきです。また、問い合わせやデータの操作のコマンドは、1つのテーブルに対して最大1つのインデックスだけ使用することに注意して下さい。