MySQL CHECK 约束写入非法值时为什么没有报错

MySQL 的 CHECK 约束写入非法值却没有报错，通常不是约束“失灵”，而是写入语句或表达式走了另一条语义：约束可能是 NOT ENFORCED，语句可能带了 IGNORE，或者表达式遇到 NULL 后得到的是 UNKNOWN。先查定义和警告，再判断数据是否真的落库，往往比直接重建表更快。

先看约束到底是不是 ENFORCED

第一步不要只看建表脚本，直接查看当前表定义。MySQL 支持 [NOT] ENFORCED：省略时或写成 ENFORCED 才会检查；写成 NOT ENFORCED 时，约束仍然存在，但不会阻止不符合条件的行。

-- 先确认当前表的真实约束定义，不依赖迁移文件的旧内容
SHOW CREATE TABLE user_profile\G

-- 再查看约束表达式和是否强制执行
SELECT tc.CONSTRAINT_NAME,
       tc.ENFORCED,
       cc.CHECK_CLAUSE
FROM information_schema.TABLE_CONSTRAINTS AS tc
JOIN information_schema.CHECK_CONSTRAINTS AS cc
  ON cc.CONSTRAINT_SCHEMA = tc.CONSTRAINT_SCHEMA
 AND cc.CONSTRAINT_NAME = tc.CONSTRAINT_NAME
WHERE tc.CONSTRAINT_SCHEMA = DATABASE()
  AND tc.TABLE_NAME = 'user_profile'
  AND tc.CONSTRAINT_TYPE = 'CHECK'; -- 只列出当前库这张表的 CHECK

如果结果是 NO，原因已经明确：不要继续用“换一种非法值”的方式测试，而应通过 ALTER TABLE 将目标约束改为强制执行，并先清理已经存在的脏数据。若是 YES，继续检查本次写入语句。

IGNORE 会让违规写入只留下警告

普通的 INSERT、UPDATE、REPLACE 以及批量导入遇到 FALSE 的 CHECK 条件时会报约束错误。但 INSERT IGNORE、UPDATE IGNORE 等语句会改变处理方式：违规行被跳过，同时产生 warning。应用只检查影响行数或没有读取 warnings，就很容易误以为非法值已经写入。

-- 这个约束只允许年龄落在业务范围内
CREATE TABLE user_profile (
  id BIGINT PRIMARY KEY,
  age INT,
  CONSTRAINT ck_user_profile_age CHECK (age BETWEEN 0 AND 120)
); -- 省略 ENFORCED，现代 MySQL 默认强制执行

-- IGNORE 不应作为静默导入的默认选项
INSERT IGNORE INTO user_profile (id, age)
VALUES (1, 180); -- 违规行可能被跳过，而不是写入 180

-- 立即读取警告，确认是否发生了 CHECK 违规
SHOW WARNINGS;

排查时可以把 INSERT IGNORE 暂时改成普通 INSERT，让错误直接暴露给事务或任务日志。批量导入确实需要容错时，也要把 warnings 数量和跳过行记录下来，不能只依赖“SQL 执行成功”。

NULL 为什么没有触发看起来明显的非法条件

CHECK 约束不是简单的“表达式不为真就拒绝”。MySQL 手册规定，条件结果为 TRUE 或 UNKNOWN 时可以通过，只有 FALSE 才构成约束违规。SQL 的三值逻辑会让 age >= 18 在 age 为 NULL 时得到 UNKNOWN，因此下面这条记录可能被接受。

-- 只限制非空年龄的范围；NULL 会让比较结果变成 UNKNOWN
CREATE TABLE member (
  id BIGINT PRIMARY KEY,
  age INT,
  CONSTRAINT ck_member_adult CHECK (age >= 18)
);

-- 如果业务要求“必须填写且至少 18 岁”，把非空条件写进约束
ALTER TABLE member
  DROP CHECK ck_member_adult,
  ADD CONSTRAINT ck_member_adult CHECK (age IS NOT NULL AND age >= 18); -- 同时拒绝 NULL

-- 复查存量数据，避免新约束因脏数据无法启用
SELECT id, age
FROM member
WHERE age IS NULL OR age 

把“没报错”变成可复查的检查清单

生产排查可以按下面顺序记录，避免把三个问题混在一起：

还要留意约束表达式使用的是执行时 SQL mode；如果表达式依赖类型转换或字符串比较，不同连接的 SQL mode 可能带来不同结果。表结构变更完成后，用普通写入语句做一条明确失败的回归用例，再检查存量数据和应用日志。

常见问题

CHECK 约束能不能引用另一张表？

不能。CHECK 表达式不允许子查询，也不能引用其他表的列；跨表一致性应考虑外键或在事务中显式校验。

如何只查看某个约束的强制状态？

在 information_schema.TABLE_CONSTRAINTS 中按库名、表名和约束名过滤，并结合 CHECK_CONSTRAINTS.CHECK_CLAUSE 查看原始条件。

为什么应用说成功但数据没变？

最常见是使用了 IGNORE，违规行被跳过。把影响行数、warnings 和事务提交结果一起记录，才能区分“成功写入”和“成功执行但跳过”。