SQL CHECK约束的用法与取值范围限制

在业务开发中，仅靠应用层代码校验数据往往不够可靠。如果接口被绕过或代码出现逻辑漏洞，数据库中就可能存入非法的状态码或超出范围的数值。CHECK 约束是数据库层面最后一道防线，它要求每条插入或更新的记录必须满足指定的布尔条件，否则直接拒绝操作。

先复现：不加 CHECK 会发生什么

假设我们有一张订单表 orders，其中 status 字段只允许 'pending'（待处理）、'paid'（已支付）和 'cancelled'（已取消），discount_rate（折扣率）必须在 0 到 1 之间。如果没有数据库约束，仅靠后端枚举判断，一旦有人直接连接数据库或通过未校验的脚本写入数据，就会出现脏数据。

例如，执行以下插入语句：

INSERT INTO orders (order_id, status, discount_rate)
VALUES (1001, 'shipped', 1.5);

在没有任何约束的情况下，这条记录会成功入库。status 变成了业务未定义的 'shipped'，discount_rate 超过了 100%。这种数据污染会导致后续统计报表错误，甚至引发线上故障。

CHECK 条件不满足时 INSERT 被拒绝

如上图所示，当引入 CHECK 约束后，同样的非法插入操作会被数据库引擎拦截，并返回明确的约束违反错误。这确保了无论数据来自哪个入口，只要不符合规则就无法落地。

列级与表级 CHECK 的写法

CHECK 约束可以定义在单个列上，也可以定义在表级别以引用多个列。

列级约束：限制单列范围

在建表时，可以直接在列定义后添加 CHECK 子句。这种方式适合简单的范围限制或枚举值检查。

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    status VARCHAR(20) CHECK (status IN ('pending', 'paid', 'cancelled')),
    discount_rate NUMERIC(5, 4) CHECK (discount_rate >= 0 AND discount_rate <= 1),
    created_at TIMESTAMP DEFAULT NOW()
);

这里 status 只能取指定的三个值之一，discount_rate 被限制在 [0, 1] 区间内。如果插入 discount_rate = 1.2，数据库会抛出错误。

表级约束：表达跨列逻辑

当约束条件涉及两个或多个列时，必须使用表级约束。例如，要求订单的 start_at 时间不能晚于 end_at 时间。

CREATE TABLE promotions (
    promo_id SERIAL PRIMARY KEY,
    start_at TIMESTAMP NOT NULL,
    end_at TIMESTAMP NOT NULL,
    CONSTRAINT chk_time_range CHECK (start_at <= end_at)
);

注意，表级约束通常使用 CONSTRAINT 名称 CHECK (...) 的格式，这样在报错时能明确指出是哪个约束失败，便于排查。

从单列范围到跨列条件并区分 NULL

上图展示了列级约束与表级约束的区别，以及 NULL 值在约束判断中的特殊路径。可以看到，单列约束直接作用于字段值，而表级约束则评估行内多个字段的逻辑关系。

NULL、已有数据与 ALTER TABLE 的坑

在使用 CHECK 约束时，NULL 值的处理和已有数据的校验是两个常见的陷阱。

UNKNOWN 与 NOT NULL 的关系

在 SQL 标准中，CHECK 约束的条件计算结果有三种可能：TRUE、FALSE 和 UNKNOWN（通常为 NULL 参与运算的结果）。只有当结果为 FALSE 时，约束才会被违反并拒绝操作；如果结果为 TRUE 或 UNKNOWN，操作都会被允许。

这意味着，如果你定义 CHECK (discount_rate > 0)，插入 NULL 是允许的，因为 NULL > 0 的结果是 UNKNOWN，而非 FALSE。如果业务要求该字段必填且大于 0，必须同时加上 NOT NULL 约束：

discount_rate NUMERIC(5, 4) NOT NULL CHECK (discount_rate > 0)

添加约束前检查历史数据

对于已经存在的表，使用 ALTER TABLE 添加 CHECK 约束时，数据库默认会扫描全表验证现有数据是否满足新约束。如果存在脏数据，添加操作会失败。

-- PostgreSQL 和 SQL Server 支持在添加时选择是否验证已有数据
ALTER TABLE orders 
ADD CONSTRAINT chk_discount_valid 
CHECK (discount_rate BETWEEN 0 AND 1);

在 PostgreSQL 中，可以使用 NOT VALID 选项跳过对已有数据的检查，仅对新插入或更新的数据生效，随后再异步验证旧数据。而在 MySQL 8.0.16 之前，CHECK 约束会被解析但忽略，8.0.16 之后才正式支持并强制校验。SQLite 则在创建表时支持，但在某些 ALTER TABLE 操作中支持有限。因此，在执行变更前，务必先查询确认历史数据的合规性：

SELECT COUNT(*) FROM orders WHERE discount_rate < 0 OR discount_rate > 1;

如果计数不为 0，需要先清洗数据或修正异常记录，再添加约束。

确定边界：CHECK 何时不够用

虽然 CHECK 约束非常有用，但它并非万能。它主要适用于单行内的静态规则。以下场景应考虑其他方案：

1. 跨表引用：CHECK 约束通常不能引用其他表的数据（部分数据库如 PostgreSQL 支持函数调用间接实现，但不推荐）。如果需要确保外键关联的有效性，应使用 FOREIGN KEY 约束。
2. 动态规则：如果规则依赖于配置表或频繁变化的业务参数，硬编码在 CHECK 中会导致维护困难。此时应在应用层或使用触发器（Trigger）处理。
3. 复杂业务流程：涉及多步事务或状态机流转的逻辑，单纯的值域检查无法覆盖状态转换的合法性，需由应用服务层控制。

在迁移落地时，建议先在测试环境模拟全量数据校验，确认约束不会阻断正常业务流。对于核心业务表，CHECK 约束是提升数据质量的低成本高收益手段，值得优先实施。

参考资料

• PostgreSQL CHECK constraints
• MySQL CHECK constraints
• SQL Server CHECK constraints
• SQLite CREATE TABLE constraints