PolarDB:概要

次のようなテーブルがあるとします。

    CREATE TABLE test1 (
        id integer,
        content varchar
    );

アプリケーションが次のような形式のクエリを多数発行するとします。

    SELECT content FROM test1 WHERE id = constant;

事前の準備がない場合、システムは test1 テーブル全体を行ごとにスキャンして、一致するすべてのエントリを検索しなければなりません。test1 に多数の行があり、クエリが返す行数が少数 (おそらく 0 行または 1 行) の場合、これは明らかに非効率なメソッドです。しかし、システムが id 列にインデックスを維持するよう設定されている場合、一致する行を検索するためのより効率的なメソッドを使用できます。たとえば、検索木を数レベルたどるだけで済む場合があります。

同様のアプローチは、ほとんどのノンフィクション書籍で使用されています。読者が頻繁に調べる用語や概念は、書籍の最後にあるアルファベット順のインデックスにまとめられています。関心のある読者は、インデックスを素早く調べて該当するページにたどり着くことができます。書籍全体を読んで目的の資料を見つける必要はありません。読者が調べる可能性の高い項目を予測するのが作成者の仕事であるのと同様に、どのインデックスが有用かを予測するのがデータベースプログラマーの仕事です。

次のコマンドを使用して、前述のように id 列にインデックスを作成できます。

    CREATE INDEX test1_id_index ON test1 (id);

test1_id_index という名前は自由に選択できますが、後でインデックスの目的を思い出せるような名前を選択することを推奨します。

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

インデックスが作成されると、それ以上の操作は必要ありません。システムは、テーブルが変更されるとインデックスを更新し、シーケンシャルテーブルスキャンよりも効率的であると判断した場合にクエリでインデックスを使用します。ただし、ANALYZE コマンドを定期的に実行して統計情報を更新し、クエリプランナーが適切な判断を下せるようにする必要がある場合があります。

インデックスが作成されると、システムはテーブルとの同期を維持する必要があります。これにより、データ操作にオーバーヘッドが生じます。したがって、クエリでほとんど使用されない、またはまったく使用されないインデックスは削除すべきです。