UNIQUE制約は「単なる重複防止」ではない
データベース設計においてUNIQUE制約は最も基本的な制約の一つですが、実務では「とりあえず重複を防げればいい」という安易な設定が、後になって深刻な運用トラブルを招くことがよくあります。単なるデータ整合性の担保だけでなく、インデックスの性質やNULLの扱いという「DB内部の挙動」を理解することが、真のDBAへの第一歩です。
NULLは「値」ではないという事実
多くのRDBMS（PostgreSQLやOracleなど）において、UNIQUE制約はNULLを「値」として扱わない、あるいは「NULLはNULLと等しくない」という仕様を持っています。つまり、カラムにNULLを許容している場合、同じカラムに何個でもNULLを挿入できてしまいます。
かつて私が担当したシステムでは、会員番号にUNIQUE制約をかけていたものの、退会済みユーザーをNULLで更新する仕様だったため、後に「退会済みユーザーが複数存在してしまい、バッチ処理で一意検索ができずにエラーが多発する」という事態に陥りました。NULLを許容するか、あるいは「NULLを禁止して空文字で管理する」か、あるいは「複合UNIQUEインデックスでNULLを排除する」か、設計段階でビジネスロジックを深く考慮する必要があります。
パフォーマンスに直結するインデックス設計
UNIQUE制約を定義すると、内部的には自動的にUNIQUEインデックスが作成されます。ここで注意すべきは、「制約のためだけのインデックス」が肥大化し、書き込み負荷を増大させるリスクです。
例えば、ログテーブルなどの「頻繁にINSERTが発生する巨大なテーブル」に対して、安易にUNIQUE制約を付与すると、インデックスの再構築コストが無視できないレベルまで膨れ上がります。本当に制約が必要な箇所と、アプリケーション側で制御すべき箇所を峻別し、場合によっては制約を貼らずに「SELECT FOR UPDATE」や「楽観的ロック」で制御することも、高負荷なシステムでは立派な戦略です。
実務での教訓：後付けの制約はリスクが高い
既存のテーブルに後からUNIQUE制約を追加しようとすると、テーブル内に既に重複データが存在している場合、制約の適用に失敗し、サービス停止を余儀なくされることがあります。
実務では、「データ投入前に制約を貼る」のが大原則です。もし後付けが必要な場合は、必ず事前に重複チェッククエリを流し、データクレンジングを完了させてから、`NOT VALID`のような「制約の遅延評価」が可能な機能を持つDBであればそれを活用してください。
制約は、システムが健やかに育つための「防波堤」です。その防波堤をどこに、どの高さで築くのか。それが、私たちDBAの腕の見せ所なのです。
コメント