MySQL CHECK 约束怎样处理 NULL 值

MySQL 的 CHECK 表达式结果为 TRUE 或 UNKNOWN 时都可以通过，只有 FALSE 才违反该约束。因此 CHECK (score BETWEEN 1 AND 5) 不会单独禁止 NULL。评分必须填写时，优先把列声明为 NOT NULL，再用 CHECK 限制范围；条件必填时，在表达式里显式写出 IS NOT NULL。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.html

先保护两条不同的数据规则

以反馈评分为例，我会先拆开两个问题：评分是否允许暂缺，以及填写后是否合法。把它们混写成“必须在 1 到 5 之间”，容易让维护者以为范围表达式已经包含了必填含义。本文以 MySQL 8.4 为说明范围，示例为原创设计，没有运行数据库或提供实测输出。

这里保护的是数据完整性：导入程序、后台表单、批处理脚本都可能成为写入入口。应用层规则可以帮助用户纠错，表结构则需要准确表达每个入口共同遵守的规则。CHECK 不能代替访问权限或参数化查询，本文也不把普通的空值遗漏描述为已发生的攻击。

NULL 怎样让范围判断成为 UNKNOWN

当 score 为 NULL 时，范围比较并不能判断它在范围内还是范围外，得到 UNKNOWN。关键点在于，CHECK 接受 UNKNOWN，因而允许空值的列配合纯范围约束，表达的是“有值时满足范围”，并非“必须有值”。

表格是表达式语义推导，不是数据库执行回执。不要写 score = NULL 来判断空值；应使用 IS NULL 或 IS NOT NULL。对 NULL 做普通相等比较，不能得到想要的空值判断。

分级控制：可选字段、必填字段、条件必填

可选评分允许 NULL，必填评分使用 NOT NULL。下面两张表刻意保留相同的范围条件，只改变列的空值属性，让规则的差别落在明确位置。

-- 演示表：备注评分允许暂缺，但已填写时必须落在 1 到 5。
CREATE TABLE feedback_optional (
    id BIGINT PRIMARY KEY,
    score INT NULL,
    CONSTRAINT ck_feedback_optional_score
        CHECK (score BETWEEN 1 AND 5) ENFORCED
);

-- 必填评分：非空规则和范围规则各自表达，方便维护。
CREATE TABLE feedback_required (
    id BIGINT PRIMARY KEY,
    score INT NOT NULL,
    CONSTRAINT ck_feedback_required_score
        CHECK (score BETWEEN 1 AND 5) ENFORCED
);

在 optional 表中，NULL 是合法的“暂缺”；在 required 表中，NOT NULL 独立禁止空值，范围约束处理超出区间的已填数值。列名保持可读，约束名加表名前缀，便于定位规则。不要用默认值 0 填充所有缺失评分：0 在这个业务里不属于有效评分，也不等同于尚未评分。

如果只有提交后才要求评分，整个列设为 NOT NULL 就太强。下面用 submitted 表示草稿与提交态，并明确每一种状态允许的组合：

-- 条件必填：草稿可不评分，提交态必须有有效评分。
CREATE TABLE feedback_submission (
    id BIGINT PRIMARY KEY,
    submitted TINYINT NOT NULL DEFAULT 0,
    score INT NULL,
    CONSTRAINT ck_feedback_submission_state
        CHECK (submitted IN (0, 1)) ENFORCED,
    CONSTRAINT ck_feedback_submission_score
        CHECK (
            (submitted = 0 AND (score IS NULL OR score BETWEEN 1 AND 5))
            OR
            (submitted = 1 AND score IS NOT NULL AND score BETWEEN 1 AND 5)
        ) ENFORCED
);

草稿允许空评分或 1 到 5 的评分；提交态只允许 1 到 5 的非空评分。submitted 本身被限制为非空的 0 或 1，避免状态字段再引入未知值。NULL 评分在提交分支中，因为 IS NOT NULL 为 FALSE，即使范围部分为 UNKNOWN，该分支也不会因此获得通过条件。

把规则定义与业务预期一起留存

我更倾向在变更说明中写清“NULL 在这个字段代表什么”，而不只保存一段 DDL。可记录表名、约束名、是否执行、允许空值的业务阶段，以及规则调整原因。MySQL 8.4 中，ENFORCED 表示执行约束，省略该子句也默认执行；NOT ENFORCED 只是保留定义，不会约束写入。

迁移现有数据时，先明确已有空值应补填、保留还是退回待处理状态，再安排表结构变更。不要给所有缺失值随意补一个看似合规的评分；这会把“未填写”改成不真实的业务事实。本文不提供可直接套用到生产库的批量更新命令。

能否只用 CHECK (score IS NOT NULL AND score BETWEEN 1 AND 5)？

可以表达禁止空值的要求；但对始终必填的单列，直接声明 NOT NULL 更直观，也能让查看列定义的人立即看出必填属性。

CHECK 接受 UNKNOWN，WHERE 也会保留它吗？

不要把约束接受条件套到筛选条件。查询筛选和约束检查承担的任务不同；分析空值时应分别理解所用语句的规则。

已经写了 CHECK，为什么无效值仍能写入？

先区分 NULL 引出的 UNKNOWN、定义中的 NOT ENFORCED，以及实际业务想限制的字段是否出现在表达式中。这些是不同原因，不能用“CHECK 不支持空值”概括。

技术依据：MySQL 8.4 CHECK Constraints 官方说明。