Posted inMySQL

MySQL 8 の Check 制約：不正データを「入り口」で完全にブロックする

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

なぜバックエンドだけに任せてはいけないのか？

MySQLの旧バージョン（5.7など）を使っていた方なら、CHECK 句を書いてもデータベースが平然と不正なデータを受け入れてしまい、「裏切られた」ような気分になった経験があるのではないでしょうか。バージョン 8.0.16 より前, MySQLは構文としては受け付けるものの、実際には実行（強制）していませんでした。「価格は正の値」「年齢は18歳以上」といったロジックは、すべてアプリケーション層に丸投げされていたのです。

バックエンドを盲信することは、高くつく間違いです。以前、あるECサイトで、従業員が管理ツールから直接、商品の価格を誤ってマイナスの値で入力してしまうというトラブルがありました。データベース側に制約がなかったため、システムは「-10万円」という価格を受け入れてしまい、わずか10分間に数百件の注文エラーが発生しました。Check制約は、コード、インポートスクリプト、あるいは手動操作のいずれからデータが来ようとも、不正なデータを「水際」で食い止める最終防衛ラインとして機能します。

テーブル構造そのものにルールを定義することで、MySQLは違反する INSERT や UPDATE を断固として拒否します。これによりデータは常にクリーンで一貫性を保ち、バックエンドエンジニアのバリデーション作業の負担を軽減してくれます。

基本の実装：制約に名前を付けるのを忘れずに

前提条件として、MySQL 8.0.16 以降を実行している必要があります。それより古いバージョンでは、警告なしに制約が無視されるため、システムにとって非常に危険です。

以下は、安全を確保するために私がよく行う商品テーブルの設定方法です：

CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    product_name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2),
    stock_quantity INT,
    -- 価格を正の値に制限する制約
    CONSTRAINT chk_price_positive CHECK (price > 0),
    -- 在庫数を負にしない制約
    CONSTRAINT chk_stock_min CHECK (stock_quantity >= 0)
);

小さいながらも非常に重要な注意点：制約には必ず明示的な名前（chk_price_positive など）を付けましょう。MySQLに products_chk_1 のような名前を自動生成させてしまうと、後でデバッグしたり削除したりする際に非常に苦労することになります。

ルールに違反するレコードを挿入してみましょう：

INSERT INTO products(product_name, price, stock_quantity) 
VALUES ('iPhone 15', -100, 10);

MySQLは即座にエラーを返し、実行をブロックします：Check constraint 'chk_price_positive' is violated.

3つの実践的な活用シーン

実際のプロジェクトでは、ロジックは単なる大小比較よりも複雑になることがあります。ここでは、より柔軟な3つの活用方法を紹介します。

1. 複数列にまたがる制約 (Multi-column)

キャンペーンテーブルなどで、終了日は必ず開始日より後でなければならない場合、Check制約を使えば非常にスマートに処理できます。

CREATE TABLE promotions (
    id INT AUTO_INCREMENT PRIMARY KEY,
    start_date DATE,
    end_date DATE,
    CONSTRAINT chk_promo_dates CHECK (end_date >= start_date)
);

2. ENUMの代わりにIN演算子を使用

MySQLの ENUM 型は、変更が必要になった際に少し硬直的（扱いにくい）な面があります。私は柔軟性を高めるために、VARCHAR と Check制約を組み合わせて使うことがよくあります：

CREATE TABLE orders (
    id INT AUTO_INCREMENT PRIMARY KEY,
    status VARCHAR(20),
    CONSTRAINT chk_order_status CHECK (status IN ('pending', 'processing', 'shipped', 'cancelled'))
);

3. 既存のテーブルへの適用

users テーブルに数百万行のデータがあるような大規模なテーブルに制約を追加する場合は注意が必要です。新しいルールを追加するには ALTER TABLE を使用します：

ALTER TABLE users 
ADD CONSTRAINT chk_user_age CHECK (age >= 18);

警告： もしテーブル内に一人でも違反するデータ（15歳のユーザーなど）が存在する場合、このコマンドは即座に失敗します。ルールを適用する前に、不正データをクリーンアップする必要があります。

パフォーマンスと知っておくべき制限事項

Check制約によってシステムが遅くなることを懸念する人もいます。実際には、その影響は極めて軽微（通常1%未満）であり、Trigger（20-30%のオーバーヘッドが発生する可能性がある）を使用するよりもはるかに最適化されています。ストレージエンジン層でチェックを行うことで、最短でエラーを返すことができます。

ただし、このツールも万能ではありません。以下の3つの大きな制限を覚えておいてください：

  • NOW() や CURRENT_TIMESTAMP() のような非決定論的（non-deterministic）な関数は使用できません。
  • 他のテーブルの列を参照することはできません（その場合は外部キーを使用してください）。
  • チェック式の中でサブクエリを使用することは許可されていません。

私の経験からのアドバイス：価格、数量、固定のステータスといった「不変のルール」には、Check制約を優先的に使用してください。一方で、時期によって頻繁に変わるようなビジネスロジックについては、データベーススキーマを頻繁に変更しなくて済むよう、アプリケーション層に留めておくのが賢明です。

Share:
Tags: