Postgres 10.Xの2つのサンプルテーブルを想定します。
CREATE TABLE public.order (
id VARCHAR(36) NOT NULL,
...
)
CREATE TABLE public.suborder (
id VARCHAR(36) NOT NULL,
order_id VARCHAR(36) NOT NULL,
...
CONSTRAINT fk_order FOREIGN KEY (order_id) REFERENCES public.order(id)
)
すべてのIDは単純なUUIDです。 suborder
はorder_id
から頻繁に照会されています。一意の(UUID)値を参照していても、order_id
に個別のインデックスを作成することには意味がありますか?
何かのようなもの:
CREATE INDEX suborder_order_idx ON public.suborder(order_id)
通常、外部キー列にインデックスを設定することをお勧めします。これは、マスターテーブルと詳細テーブルが頻繁に結合されている場合、またはマスターテーブルで削除/更新が発生した場合に役立ちます。この場合、インデックスがないため、詳細テーブルのフルスキャンが行われ、外部キーが適用されます。
上記のいずれかがシステムに当てはまる場合は、インデックスを追加することをお勧めします。
サイドノート。 idsはguid値を格納するので、範囲で検索することはないでしょう。その場合、ハッシュインデックスは、「通常の」Bツリーインデックスよりもはるかに優れた選択肢になります。
親テーブルが削除(またはPKの更新)を受け取った場合、外部キー列のインデックス作成も役立ちます。削除された親テーブルのすべての行について、データベースは、親を参照する行がまだあるかどうかを参照テーブルをチェックする必要があります。このチェックは、FK列にwhere
条件を持つ子テーブルから選択することで行われます。明らかに、FK列にインデックスが付けられている場合、これはより高速です(これは、Firebird、Oracle、SQL Server、またはDB2などの他のDBMSにも当てはまります)。