他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

Chapter 7. インデックス

Table of Contents
7.1. 序文
7.2. インデックスの型
7.3. 複数列インデックス
7.4. 一意インデックス
7.5. 関数インデックス
7.6. 演算子クラス
7.7. キー
7.8. 部分インデックス
7.9. インデックス利用の検証

インデックスはデータベース性能を向上させるための一般的な方法です。インデックスがあると、ない場合に比べてデータベースサーバーが特定の行をずっと速く見つけ抽出できます。しかしインデックスはデータベース全体にとってはオーバーヘッドの追加となるため、繊細な注意が必要です。

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を読んでください。

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

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