数据库完整性这事，老生常谈，但真正落地到日常开发里，你会发现很多团队的“完整性”全靠后端代码硬撑。布尔字段存成 0/1 靠注释约定，年龄字段靠业务层 if 判断，状态字段靠枚举类在代码里兜底。一旦业务侧漏判一个分支，脏数据就悄悄进了库。MySQL 8 的检查约束（CHECK 约束）就是来解决这个痛点的。本文不聊虚的，直接讲清楚 MySQL 8 检查约束的语法细节、适用场景、与 ENUM / 触发器的取舍，以及我实际踩过的坑，帮你把这套机制真正用起来。

先从背景说起。早在 MySQL 8.0.16 之前，SQL 标准里的 CHECK 约束在 MySQL 中就是个“摆设”——你写上去，MySQL 解析器认得它，但执行时直接忽略，数据该咋进还咋进。那个年代，大家要么用 ENUM 顶着，要么写触发器，要么干脆全靠应用层自觉。直到 8.0.16 版本正式启用了 CHECK 约束的强制校验，这个“迟到”多年的特性才算真正落地。如果你还在用 5.7 或更老的版本，下面的内容当参考即可，真要让约束生效，升级是前提。

1. 被“无视”多年的 CHECK 约束：从 MySQL 8.0.16 说起

1.1 为什么说 MySQL 的 CHECK 约束“迟到”了十年

SQL:1992 标准里就有 CHECK 约束，MySQL 官方文档也很早就写了 CHECK 子句的语法，但实现上一直留了个空。早期的 MySQL 之所以不执行 CHECK，一个重要原因是设计哲学偏向“轻量”：解析器只要保证语法兼容，执行器则放行所有数据，把校验责任甩给客户端。这个设计在当时有争议，但对很多只把 MySQL 当存储层的应用来说，影响并不大，因为大量的业务校验确实在应用层做了。

真正的转折是 8.0.16，MySQL 官方终于把 FOREIGN KEY 之外的约束补齐，CHECK 从“语法合法”变成了“真正强制执行”。用一句话概括：8.0.16 之前，CHECK 写成什么样都行，反正不拦数据；8.0.16 之后，只要约束条件计算结果为 FALSE，INSERT 或 UPDATE 直接报错回滚。如果你从 5.7 迁移到 8.0，又恰好有历史表里定义了未被执行的 CHECK，升级后第一次写入就报错，这类兼容性问题在迁移中并不少见。

1.2 CHECK 约束到底解决什么问题

最直白的回答：把简单、稳定、不常变的业务规则放进数据库，让数据库拒绝非法数据。举例：

• 年龄必须大于 0 且小于 150；
• 分数必须在 0 到 100 之间；
• 订单金额不能为负数；
• 性别只能是 M / F / U 三个值之一；
• 时间字段必须满足结束时间大于开始时间。

这些规则往往横跨多张表、多个接口，如果只靠应用层，每个写入入口都要写一遍 if 判断，漏一个就是事故。CHECK 约束把规则下沉到表定义中，相当于数据库自己长了一道“闸门”。注意一个关键点：CHECK 约束更适合规则稳定、简单、纯字段内或同行字段间的校验。跨表校验、复杂业务状态机、需要查库存这种动态校验，CHECK 做不了，也别硬做，那是触发器或应用层的事，这在下文会详细展开。

2. 检查约束的核心语法与设计思路

2.1 建表时定义 CHECK 约束的三种写法

第一种，列级约束，直接跟在字段定义后面，最适合单字段简单规则：

CREATE TABLE user_profile ( id INT PRIMARY KEY, age INT CHECK (age >= 0 AND age <= 120), score INT CHECK (score BETWEEN 0 AND 100) );

第二种，表级约束，独立写在所有列定义之后。好处是可以给约束起名字，还可以跨字段做比较：

CREATE TABLE event_session ( id INT PRIMARY KEY, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, CONSTRAINT chk_session_time CHECK (end_time > start_time) );

第三种，使用 CHECK (expr) 加比较复杂的表达式，支持 AND、OR、IN、LIKE、函数调用等：

CREATE TABLE app_user ( id INT PRIMARY KEY, email VARCHAR(255), phone VARCHAR(20), -- 邮箱和手机号至少填一个 CONSTRAINT chk_contact CHECK (email IS NOT NULL OR phone IS NOT NULL) );

这里最容易被忽视的是 NULL 语义。当 CHECK 表达式的结果为 NULL 时，MySQL 判定为“通过”。比如CHECK (age > 0)，如果插入时 age 为 NULL，NULL > 0的结果不是 FALSE 而是 NULL，按规则不算违规，插入成功。换句话说，想挡 NULL，就必须在 CHECK 里显式加age IS NOT NULL，否则就得依赖字段本身的 NOT NULL 约束。我在实际项目里见过有人以为 CHECK 能顺带解决非空问题，结果 NULL 照样入库，这种误解一定要提前纠正。

2.2 修改表结构：ADD 和 DROP CHECK

历史表加约束不需要重建表，用 ALTER TABLE 即可：

ALTER TABLE user_profile ADD CONSTRAINT chk_age CHECK (age BETWEEN 0 AND 120);

删除约束同样方便：

ALTER TABLE user_profile DROP CHECK chk_age;

有两种情况要特别留神。

情况一：存量数据不合规时，ADD CHECK 会直接失败。比如表里已经有 500 万条记录，其中 30 条 age 是负数，这时执行 ADD CHECK 会立刻报错，提示“Check constraint violated”，整条 ALTER 语句不生效。方案是先清洗数据，把非法记录处理掉，再添加约束。反过来说，这也侧面验证了约束确实是在“查历史账”，不是只挡新写入。

情况二：MySQL 8.0.16 到 8.0.19 版本中，CHECK 约束不能与ENUM字段混用?其实官方文档没有禁止混用，但 MySQL 8.0.16 的早期实现与某些类型组合存在行为差异，严格模式下可能产生预期外报错。稳妥的做法是：业务规则不复杂的直接上 CHECK，别把 ENUM 和 CHECK 叠加在同一字段上，避免语义混乱，也避免在跨版本升级时踩兼容坑。

2.3 约束命名与可见性

建表时不写 CONSTRAINT 名字，MySQL 会自动生成，比如user_profile_chk_1。这种名字在后续 DROP 时很难受，你还得先查。所以我的习惯是所有约束都显式命名，格式统一为chk_表名_字段名或chk_表名_业务含义。

想查看某张表已经有哪些约束，可以执行：

SHOW CREATE TABLE user_profile\G

或者查信息 schema：

SELECT CONSTRAINT_NAME, CHECK_CLAUSE FROM information_schema.CHECK_CONSTRAINTS WHERE CONSTRAINT_SCHEMA = 'your_db';

实际运维中，我建议把约束和索引、外键一起纳入表结构评审清单。代码评审只盯 PHP / Java 代码里的判断是不够的，SHOW CREATE TABLE才是看数据完整性设计是否到位的快速路径。

3. 实操过程：把业务规则下沉到数据库

3.1 一个完整的用户表约束设计案例

空谈语法没意思，直接看一个模拟项目 X 中的真实设计。假设我们要建一张用户留存分析表，字段包括用户ID、设备平台、年龄、注册渠道、金币余额、最后登录时间。业务规则如下：

• 平台只有 iOS / Android / H5 三种；
• 年龄范围限定 1 到 120；
• 金币余额不能为负；
• 注册渠道限定为自然量 / 广告 / 地推 / 老带新；
• 最后登录时间不能早于注册时间。

建表 SQL 可以这样写：

CREATE TABLE user_retention ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, platform VARCHAR(10) NOT NULL, age TINYINT UNSIGNED NOT NULL, register_channel VARCHAR(20) NOT NULL, coin_balance DECIMAL(10,2) NOT NULL DEFAULT 0, registered_at DATETIME NOT NULL, last_login_at DATETIME DEFAULT NULL, CONSTRAINT chk_user_retention_platform CHECK (platform IN ('iOS', 'Android', 'H5')), CONSTRAINT chk_user_retention_age CHECK (age BETWEEN 1 AND 120), CONSTRAINT chk_user_retention_coin CHECK (coin_balance >= 0), CONSTRAINT chk_user_retention_channel CHECK (register_channel IN ('natural', 'ad', 'offline', 'referral')), CONSTRAINT chk_user_retention_time CHECK (last_login_at IS NULL OR last_login_at >= registered_at) );

逐个解释设计意图：

• 平台字段用 VARCHAR 加 CHECK 而不是 ENUM。原因是历史经验里 ENUM 加新值要 ALTER TABLE，元数据变更成本高，而且 ENUM 在 ORM 映射上经常出幺蛾子。VARCHAR + CHECK 灵活性更好，加一个平台值，改约束定义即可，语义也清楚。
• 年龄用 TINYINT UNSIGNED 再配 CHECK。如果字段本身是无符号整数，负数在插入阶段就被类型规则拦住了，CHECK 再兜一层业务范围校验，双保险。
• 金币余额用 DECIMAL(10,2) 并加>= 0。为什么不用 INT 存分？因为业务上需要展示元，用 DECIMAL 更直观，也符合金额字段的通用设计。
• 最后登录时间允许 NULL，所以 CHECK 里要显式写last_login_at IS NULL OR ...，否则新用户未登录时插入会失败。这是最容易被漏掉的细节。

3.2 与 ENUM、触发器的取舍

很多读者会问：有 ENUM 和触发器，为什么还要 CHECK？我把三者的边界整理过一个对比表，便于决策：

个人建议的选型逻辑是：

• 规则简单、不变、同表内字段判断，优先 CHECK；
• 枚举值极其固定且永远不会扩展（比如“性别”），用 ENUM 可以，但要忍受 ORM 映射不便；
• 需要跨表校验（比如账户余额不能超授信额度）、需要写审计日志，必须上触发器；
• 应用层校验永远保留，数据库约束是最后防线，不是替代品。

有一类需求很容易被误导，例如“订单金额不能超过用户余额”。这属于跨表动态校验，CHECK 做不到。要严谨实现得靠事务内 SELECT 加锁或用触发器，性能代价不小，一般建议放到服务层事务里处理。不要试图把动态业务规则塞进静态约束里。

3.3 严格模式与数据校验的边界

MySQL 的sql_mode对约束校验也有影响。8.0 默认开启STRICT_TRANS_TABLES，此时如果 INSERT 的字段值本身类型不合法（比如字符串截断、超出 INT 范围），会直接报错；但 CHECK 约束校验是独立机制，它判断的是表达式结果，与 SQL_MODE 是否严格关系不大。

不过有一个组合要小心：关闭严格模式 + CHECK 约束。在非严格模式下，超范围数值可能被截断或置零，而 CHECK 在截断后基于最终值再判断。比如向age TINYINT插入 300，非严格模式下可能被截成 127（或 255），此时 CHECK 判断 127 是合规的，插入就成功了。你原本的意图可能是“拒绝 300 这个非法值”，但结果变成了“先截断再放行”。这个坑很隐蔽，建议生产环境务必保持严格模式开启，同时用 CHECK 做业务规则限制，两者职责不同。

4. 常见问题与排查技巧实录

4.1 为什么 CHECK 约束“不生效”

这是群里被问得最多的问题。一半情况是版本太低，8.0.16 之前根本不执行；另一半情况是写错了形式，比如：

CREATE TABLE t1 ( age INT, CONSTRAINT chk_age CHECK (age > 0) ) ENGINE=InnoDB;

看起来没毛病，怎么插入 age = -1 还是成功？大概率是建表时约束被忽略了。排查路径按顺序来：

1. 确认 MySQL 版本是否大于等于 8.0.16；
2. SHOW CREATE TABLE t1看建表语句里约束是否还在；
3. 查information_schema.CHECK_CONSTRAINTS确认约束存在；
4. 检查是否命中 NULL 语义——比如该行 age 实际是 NULL，NULL > 0结果为 NULL 视为通过；
5. 检查 SQL 是不是写的IGNORE或REPLACE，这两个操作会吞掉约束冲突，下文单独说。

另外，有些 ORM 框架生成表结构时会把 CHECK 子句“吃掉”。比如某些迁移工具只同步了字段、索引，却忽略了 CHECK 约束，导致你以为线上有约束，实际没有。校验手段只有一个——直接连数据库看information_schema，别只看 ORM 层的模型定义。

4.2 INSERT IGNORE 与约束冲突的坑

这是 8.0 引入 CHECK 后新增的高频问题。INSERT IGNORE的语义是“忽略错误继续”，但 CHECK 约束冲突时，MySQL 的行为是将其转换为 warning，然后插入一条“合法”的数据?不对——需要精确描述：INSERT IGNORE遇到 CHECK 冲突会跳过该行，行为类似唯一键冲突跳过。因此如果你批量灌数据时用了INSERT IGNORE，一部分脏数据会悄无声息地被丢弃，业务上表现为“数据少了”，而不是“报错”。

这个行为让我在数据订正脚本里吃过亏。当时把清洗后的用户数据回灌到新表，用了INSERT IGNORE，结果几万条非法年龄的记录被静默跳过，回灌进度看起来完成，实际缺失。复盘结论：数据订正场景禁用INSERT IGNORE，改用普通 INSERT，让冲突直接暴露；如果确实要忽略部分行，务必记录 warning 数量并人工核对。

另外REPLACE INTO也有类似的交互。REPLACE 遇到 CHECK 冲突时不会像唯一键冲突那样删除重插，而是直接报错回滚，这个行为在不同版本之间有差异，建议不要在关键写路径上用 REPLACE。

4.3 外键、分区表与 CHECK 约束的兼容性

先说结论：CHECK 约束和外键可以共存，但语义要分清楚。外键保证引用完整性（子表的某个值必须存在于父表），CHECK 保证字段自身规则。二者不冲突，但也不要指望 CHECK 能替代外键。比如“用户的部门 ID 必须存在于部门表”这种规则，用 CHECK 无法表达，只能用外键。

分区表方面，MySQL 8.0 的 CHECK 约束在分区表上同样适用，但有一个大前提：所有分区都必须满足同一套 CHECK 规则。你不能只在某个分区上单独加约束。实际开发中，分区表常用于日志、流水类大表，这类表业务规则少，CHECH 用得也不多，但一旦用了，要注意分区裁剪和约束校验之间的关系——分区裁剪发生在约束校验之前还是之后，不同版本存在差异，别依赖这个顺序写业务逻辑。

4.4 性能影响：CHECK 约束会拖慢写入吗

这是选型时大家最关心的实际问题。我的实测结论是：CHECK 约束对写入性能影响非常小，但也不是零。MySQL 在写入时需要额外计算约束表达式，对于简单比较，开销可以忽略；对于含函数或子查询的复杂表达式，开销会上升，但 CHECK 本身设计上就不鼓励写复杂表达式，所以几乎不存在性能瓶颈。

真正需要关注的性能点反而是约束设计不当导致的大量写入失败。比如某张热点表每天写入数百万行，其中大量行不满足某条新加的 CHECK，那么从加约束那一刻起，这些写入会全部失败并回滚，应用层还得处理异常重试，整体吞吐下降。所以加约束要选好时机，最好在低峰期执行，并提前用 SQL 探一下存量数据的合规比例：

SELECT COUNT(*) FROM user_retention WHERE age < 1 OR age > 120;

返回 0 才能安心加约束。这也是我处理线上表加约束的标准动作。

5. 关于约束的一些实操心得

每次聊到 CHECK 约束，总会有人把“数据库完整性”和“业务逻辑下沉”对立起来。我的态度一直很明确：数据库约束不是银弹，但它是性价比极高的防线。应用层校验是口子，数据库约束是闸门。口子漏了，闸门还能兜住。

实际工作中，我对 CHECK 约束的使用有几点总结：

第一，只在规则确定的字段上使用。所谓“确定”，就是产品不会三天两头改。性别、年龄范围、金额非负、时间先后这些属于确定场景；而“会员等级积分规则”这种一个月变三次的，别写进 CHECK，否则以后每条 ALTER 都要评审、发版，成本远大于收益。

第二，约束命名要像索引命名一样认真。线上出问题后，日志里报的是约束名，如果你的约束叫chk_1、chk_2，排查时根本对不上号。花十秒起个规范名字，省的是后面几小时。

第三，新增 CHECK 前先做存量数据体检。很多人加约束失败后才发现老数据一堆不合规，先查一遍，把违规数据清理或标记，再执行 ALTER，一气呵成不加戏。

第四，别忘了 NULL 语义。age > 0不等于“age 不能为空”，该 NOT NULL 的字段要单独声明。这个坑我在新同事的代码里见过不止一次。

最后再分享一个小技巧：写表结构变更脚本时，把 ADD CONSTRAINT 和 DROP CONSTRAINT 写成成对的迁移脚本，上一个稳定版本、下一个回滚版本。这样无论加约束后发现业务不兼容，还是大版本升级出问题，都能快速回退。检查约束用了这几年，最大的感受是它让表结构“自带说明书”，新接手的人看一眼约束定义，就知道哪些数据算合法，这比翻几个月前的需求文档效率高得多。