「NOT NULL」をただの制約だと思っていませんか？
データベースの設計において、`NOT NULL`制約は「データの品質を守るための門番」だと教わります。もちろんそれは間違いではありません。しかし、PostgreSQLの深淵を覗き込むようなエンジニアであれば、この制約が単なるバリデーションツールを超え、クエリプランナにとっての「強力なヒント（Optimizer Hint）」として機能していることに気づいているはずです。
今日は、この「一見地味な制約」が、いかにしてPostgreSQLの実行計画を最適化し、パフォーマンスの底上げに寄与しているのか、その内部構造を少し掘り下げてみましょう。
1. 執行される「NULLチェック」のコストを捨てる
クエリを書くとき、私たちは無意識のうちに条件式を組み立てます。例えば `WHERE column_a = 10` というクエリを投げたとき、PostgreSQLのプランナは内部的に「`column_a` が NULL ではないこと」という判定を含めて実行計画を立てる必要があります。
もし、その列に `NOT NULL` 制約が付与されていれば、プランナは迷わず「この列に NULL は存在しない」という事実を基に、チェックロジックをバイパスします。
微々たる差に思えるかもしれません。しかし、数億行のテーブルをスキャンするようなバッチ処理において、ループのたびに発生する「NULLかどうかの判定コスト」は、塵も積もれば山となります。`NOT NULL` 制約は、実行時の命令数を減らすための、最も安価で確実な最適化手法なのです。
2. プランナが「強気」になれる理由
`NOT NULL` 制約は、プランナに対して「統計情報」以上に強い確信を与えます。
例えば、`JOIN` を最適化する際や、`GROUP BY` を実行する際、プランナが「この列に NULL が含まれる可能性」を考慮しなくて良いということは、クエリプランの選択肢を劇的に広げます。
特に面白いのが、インデックスとの組み合わせです。
PostgreSQLのB-treeインデックスにおいて、NULLは特殊な扱いを受けますが、`NOT NULL` 制約がある列に対しては、インデックスがより「稠密（ちゅうみつ）」になります。余計なNULLのメタデータをケアする必要がないため、インデックスのツリー構造がよりシンプルに保たれ、メモリ上のキャッシュ効率も微妙に向上するのです。
3. パフォーマンストラブルシューティング：NULLが「見えない」とき
現場でよくあるのが、`NOT NULL` を設定し忘れたことで発生する「予期せぬ実行計画の劣化」です。
特定のカラムにNULLが混入してしまった場合、プランナは統計情報を更新した際に「NULLの割合」を認識します。すると、それまでインデックスを引いていたクエリが、突然「NULLの存在を考慮しなければならない」という理由だけで、コストモデルが変わってしまい、フルスキャン（Seq Scan）に転落することがあります。
トラブルシューティングの現場で「なぜか昨日まで速かったクエリが遅くなった」という相談を受けた際、私はまず、対象列に制約漏れがないか、そして `pg_stats` を見て NULL の混入率を確認します。多くの場合、`NOT NULL` 制約を後付けするだけで、プランナが元の「強気な」実行計画を取り戻してくれます。
結論：防衛的プログラミングとしての制約
私がDB設計をする際、`NOT NULL` は「可能な限り付ける」のが鉄則です。
- データ品質の担保（整合性）
- プランナの最適化情報の提供（パフォーマンス）
- アプリケーション層でのNullPointerExceptionの撲滅（堅牢性）
これら全てを、数文字の制約定義だけで手に入れられるのです。これを使わない手はありません。
もしあなたが今、既存のテーブルを眺めていて、制約が緩い場所を見つけたら、ぜひ `ALTER TABLE … SET NOT NULL` を検討してみてください。それだけで、データベースが心なしか「軽やかに」動き出すのを実感できるはずです。
データベースは、私たちが与えたヒントを裏切りません。制約を単なる「禁止事項」としてではなく、データベースへの「道しるべ」として扱うこと。それが、熟練エンジニアの流儀ではないでしょうか。
コメント