web-dev-qa-db-ja.com

Postgresの外部キー（uuid）列にインデックスを作成することには意味がありますか？

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)
postgresqldatabase-designindex
2
Mikhail Kholodkov

通常、外部キー列にインデックスを設定することをお勧めします。これは、マスターテーブルと詳細テーブルが頻繁に結合されている場合、またはマスターテーブルで削除/更新が発生した場合に役立ちます。この場合、インデックスがないため、詳細テーブルのフルスキャンが行われ、外部キーが適用されます。
上記のいずれかがシステムに当てはまる場合は、インデックスを追加することをお勧めします。

サイドノート。 idsはguid値を格納するので、範囲で検索することはないでしょう。その場合、ハッシュインデックスは、「通常の」Bツリーインデックスよりもはるかに優れた選択肢になります。

親テーブルが削除（またはPKの更新）を受け取った場合、外部キー列のインデックス作成も役立ちます。削除された親テーブルのすべての行について、データベースは、親を参照する行がまだあるかどうかを参照テーブルをチェックする必要があります。このチェックは、FK列にwhere条件を持つ子テーブルから選択することで行われます。明らかに、FK列にインデックスが付けられている場合、これはより高速です（これは、Firebird、Oracle、SQL Server、またはDB2などの他のDBMSにも当てはまります）。

2
a1ex07