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

「守り」の制約か、「攻め」の武器か。PostgreSQLのCHECK制約を再考する

PostgreSQLを長年触っていると、ふとした瞬間に「当たり前」だと思っていた機能の深淵に触れることがある。その筆頭が `CHECK` 制約だ。

多くのエンジニアにとって、これは単なる「データの整合性を担保するための防波堤」だろう。確かに、`price >= 0` や `status IN (‘draft’, ‘published’)` といった定義は、アプリケーション側のバリデーション漏れを防ぐ最後の砦として極めて優秀だ。

しかし、もし君がデータベースのパフォーマンスを極限まで絞り出そうとしているなら、`CHECK` 制約を単なる「門番」として扱うのはもったいない。これは、PostgreSQLのクエリプランナに対する、極めて強力な「ヒント」になり得るのだから。

—

プランナは「制約」を信頼している

PostgreSQLのオプティマイザは、非常に論理的だ。特に `Constraint Exclusion`（制約排除）という最適化プロセスにおいて、`CHECK` 制約は神のような存在になる。

例えば、巨大なパーティションテーブルを運用しているとき、`WHERE` 句の条件が特定のパーティションと矛盾していると判断できれば、プランナは迷わずそのパーティションへのアクセスをスキップする。これ自体は有名だが、単一テーブルのクエリでも同様のことが起きるのを知っているだろうか。

— こんなテーブルがあるとする
CREATE TABLE orders (
id serial PRIMARY KEY,
status text CHECK (status IN (‘pending’, ‘completed’, ‘cancelled’)),
created_at timestamp
);

もし、君が `WHERE status = ‘archived’` と投げたとする。もちろん、そんなデータはどこにも存在しない。しかし、プランナは `CHECK` 制約を見て、「ああ、このステータスは絶対に存在しないな」と瞬時に判断し、インデックススキャンすら行わずに結果を返すことができる。

複雑なクエリになればなるほど、この「制約に基づく論理的な枝刈り」は効いてくる。インデックスを無闇に増やす前に、制約が適切に定義されているかを確認する。これこそが、熟練のエンジニアが最初に行うチューニングの一つだ。

—

パフォーマンスの裏側：コストと評価のタイミング

もちろん、銀の弾丸ではない。`CHECK` 制約にはコストがある。

すべての `INSERT` や `UPDATE` のたびに、PostgreSQLは制約を評価する。もし制約内に重い関数や複雑なサブクエリ（実はあまり推奨されないが…）が含まれていれば、当然ながら書き込み性能は劣化する。

特に注意したいのが、「制約の妥当性を検証するタイミング」だ。
`ALTER TABLE … ADD CONSTRAINT … NOT VALID` を活用したことはあるだろうか？既存の数億行あるテーブルに制約を追加する際、通常なら `ACCESS EXCLUSIVE` ロックを長時間保持して全行スキャンが走ってしまう。だが、`NOT VALID` を使えば、ロック時間を最小限に抑えつつ、制約を追加できる。その後、バックグラウンドで `VALIDATE CONSTRAINT` を実行すればいい。大規模な商用環境では、この「作法」を知っているかどうかで、DBAとしての格が問われる。

—

トラブルシューティングの視点：なぜプランナは誤解するのか

時折、「制約を貼っているのに、プランナがそれを無視して全表スキャン（Sequential Scan）を選択する」という相談を受けることがある。

多くの場合、原因は `CHECK` 制約の記述と、クエリの `WHERE` 句の型や論理関係の不一致にある。
例えば、`CHECK` 制約で `col > 100` と定義しているのに、クエリで `col > 100.0::numeric` のように型変換を強制させると、プランナが論理的な包含関係を証明できなくなることがある。

プランナは魔法使いではない。あくまで統計情報と制約の定義を照らし合わせる「論理演算機」だ。だからこそ、我々エンジニアは、プランナが計算しやすいように、制約とクエリの論理構造をシンプルに保つ義務がある。

—

最後に：制約は設計者の「意志」だ

良いデータベース設計とは、制約によって「あり得ないデータ」を徹底的に排除する設計だ。

アプリケーション層でのバリデーションは、あくまでUXのため。データベースの `CHECK` 制約は、システム全体の整合性を守るための「絶対的な規律」だ。そして、その規律は、PostgreSQLというエンジンの最適化能力を最大限に引き出すための「道標」にもなる。

もし今、君のプロジェクトのテーブル定義を見て、`CHECK` 制約がほとんど書かれていないなら、それはまだ「最適化の余地」が残されている証拠かもしれない。

さあ、エディタを開いて、制約という名の「意志」をスキーマに刻み込もう。それが、最高にキレのあるクエリへの第一歩だ。