【テクニカル・上級編】 UNIQUE制約 – PostgreSQL

UNIQUE制約の裏側：その「一意性」は本当にコストフリーか？

PostgreSQLを触り始めて日が浅い頃、私たちは皆 `UNIQUE` 制約を「データ整合性を守るための魔法の杖」だと教わります。確かに、アプリケーション層で必死に重複チェックを実装するよりも、データベースの制約に任せる方が遥かに堅牢です。

しかし、大規模なデータセットを扱うようになると、この「便利な制約」がパフォーマンスのボトルネックとして牙を剥くことがあります。今日は、一歩踏み込んで、PostgreSQLの `UNIQUE` 制約が内部で何をしているのか、そしてそれが大規模環境でどう作用するのかを紐解いてみましょう。

1. UNIQUE制約は「インデックスの相棒」に過ぎない

まず前提として、PostgreSQLにおいて `UNIQUE` 制約は、実体としては 「一意インデックス (Unique Index)」 そのものです。制約を定義した瞬間、バックグラウンドでB-treeインデックスが作成されます。

つまり、`UNIQUE` 制約のパフォーマンス特性を語ることは、そのままB-treeインデックスの挙動を語ることと同義です。

ここでの落とし穴は、「制約がある列には、自動的にインデックスが貼られる」という事実が忘れ去られがちな点です。書き込み負荷が高いテーブルに不用意な `UNIQUE` 制約を追加すれば、それはそのまま「書き込みのたびにB-treeのリーフページを探索し、必要であればページ分割（Page Split）が発生する」というコストを意味します。

2. コンカレンシーとページロックの深い関係

特に高負荷なシステムで注意すべきなのが、「重複チェックのタイミング」 です。

PostgreSQLは、データが挿入される直前に一意性を検証します。この際、もし対象のインデックスページがメモリ（Shared Buffers）上にない場合、物理的なI/Oが発生します。さらに、並行して大量の挿入が行われると、B-treeのリーフページに対するロック競合が顕著になります。

HOT (Heap Only Tuple) 更新の阻害:

PostgreSQLが誇るHOT更新（インデックスを更新せずにヒープ領域のタプルを更新する仕組み）は、更新対象の列にインデックスが貼られていない場合にのみ有効です。つまり、`UNIQUE` 制約がついている列を更新しようとすると、たとえ値が変更されていなくても、インデックスの再挿入が発生し、HOT更新の恩恵を完全に失うことになります。

3. トラブルシューティング：一意制約が遅い時のチェックリスト

もし「特定のテーブルの `INSERT` が急激に遅くなった」と感じたら、以下の順序で疑ってみてください。

インデックスの肥大化を確認する:

`pgstattuple` 拡張を使って、インデックスの「デッドタプル率」を調べてください。頻繁な更新と削除を繰り返すテーブルでは、インデックス内部にゴミが溜まり、ツリーの深さが必要以上に増大している可能性があります。

インデックスのスキュー（偏り）:

特定のキー値に挿入が集中していませんか？ B-treeの右端（最新のシーケンシャルな値が挿入される場所）にI/Oが集中すると、そこが物理的なホットスポットになります。

インデックスの「幅」:

`UNIQUE` 制約に含める列が多すぎたり、非常に長い文字列を含んでいたりすると、インデックスページの効率が極端に落ちます。可能な限りインデックスサイズを小さく抑えるのが鉄則です。

4. 賢いエンジニアのための「部分インデックス」という選択肢

もし、あなたのアプリケーションが「有効なレコード間でのみ一意性を保証すればよい（例：削除済みフラグがあるレコードは無視する）」のであれば、通常の `UNIQUE` 制約ではなく、「部分一意インデックス (Partial Unique Index)」 を活用すべきです。

CREATE UNIQUE INDEX idx_unique_active_user
ON users (email)
WHERE deleted_at IS NULL;

これだけで、インデックスサイズは劇的に小さくなり、インデックスの保守コストも下がり、書き込み性能は向上します。制約の要件を「本当に必要な範囲」に絞り込むことこそが、高負荷環境でのパフォーマンスチューニングの醍醐味です。

最後に：制約は「コスト」であると心得る

`UNIQUE` 制約は、データ整合性を担保するための最も安価な手段であることに変わりはありません。しかし、それが決して「無料」ではないことを理解しているかどうかで、エンジニアとしての格が変わります。

アーキテクチャの設計段階で「この制約は本当に必要か？」「更新頻度はどれくらいか？」を自問自答し、必要であれば部分インデックスを検討する。そんな冷静な視点を持つことで、あなたのデータベースは、何千万行ものレコードを抱えてもなお、軽快なレスポンスを返し続けるはずです。

データベースは、正直な鏡です。私たちが書いたインデックスの数だけ、返してくれるパフォーマンスが決まります。ぜひ、その制約の向こう側まで見通す設計を心がけてください。