MySQL 8.0中如何利用CHECK约束来确保数据的业务有效性？

MySQL 8.0.16+才真正支持CHECK约束，低版本即使定义也无效；需通过SELECT @@version确认版本并实测INSERT触发报错来验证；列级CHECK仅限单列，表级可跨列校验；禁止使用NOW()等函数；建议显式命名约束；NOT ENFORCED可用于灰度启用；兼容老版本或复杂逻辑必须用触发器兜底。

CHECK 约束在 MySQL 8.0.16 及之后版本才真正生效，低于该版本（包括 8.0.0–8.0.15）定义了也白定义——插入 age = -5 或 score = 0 一样成功。

---

确认你的 MySQL 版本是否真正支持 CHECK

执行 SELECT @@version;，结果必须是 8.0.16 或更高（如 8.0.33、8.4.0）。注意：仅写 8.0 不够，很多线上环境仍是 8.0.11 或 8.0.28，而后者若未打补丁或升级，CHECK 仍被忽略。

更稳妥的验证方式是直接测试：

• 建表：CREATE TABLE t (x INT, CONSTRAINT chk_x CHECK (x > 0));
• 插入：INSERT INTO t VALUES (-1);
• 如果报错 Check constraint 'chk_x' is violated.，说明生效；否则就是“假支持”。

别信文档说“8.0 支持”，得自己跑一遍。

---

列级 CHECK 和表级 CHECK 的实际差异

列级 CHECK 只能引用当前列，语法紧凑但能力受限：

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

表级 CHECK 才能跨列做业务逻辑校验，比如“发货时间不能早于下单时间”：

CREATE TABLE orders (order_time DATETIME, ship_time DATETIME, CONSTRAINT chk_time_order CHECK (ship_time >= order_time OR ship_time IS NULL));

注意点：

• 表达式中允许 NULL 参与比较，结果为 UNKNOWN 时约束不触发（即不报错），这是 SQL 标准行为；
• 不能在 CHECK 中调用函数如 NOW()、UUID() 或子查询，MySQL 会直接报错 Function 'now' is not allowed in check constraint；
• 约束名建议显式指定（如 chk_status_valid），否则 MySQL 自动生成的名字像 t_chk_1，后续排查和删除极难定位。

---

ENFORCED vs NOT ENFORCED：可控的约束开关

MySQL 允许你创建但暂时不强制执行的 CHECK，用 NOT ENFORCED 关键字：

ALTER TABLE users ADD CONSTRAINT chk_email_format CHECK (email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$') NOT ENFORCED;

这种写法适合灰度场景：

• 先上线约束定义，观察日志或监控是否有大量违反数据；
• 修复存量脏数据后，再用 ALTER TABLE users ALTER CHECK chk_email_format ENFORCED; 激活；
• NOT ENFORCED 约束仍会出现在 information_schema.check_constraints 中，ENFORCED 字段为 NO。

别把它当“开发环境开关”随便关——生产库一旦设为 NOT ENFORCED，就等于主动放弃一层数据防线。

---

CHECK 失效时的兜底方案：触发器不是备选，是必选

如果你无法确认版本、或需兼容老版本（如 MySQL 5.7）、或要实现 CHECK 不支持的逻辑（如查另一张表、调用函数、发告警），就必须用触发器。

例如模拟“余额不能为负”：

DELIMITER $$ CREATE TRIGGER tr_check_balance_before_insert BEFORE INSERT ON accounts FOR EACH ROW BEGIN IF NEW.balance

关键提醒：

• 触发器在 BEFORE INSERT/UPDATE 阶段执行，比应用层校验更可靠；
• 务必用 SIGNAL 主动报错，不要只写 SET NEW.balance = 0 这类静默修正——业务语义会被掩盖；
• 触发器逻辑越重，写入性能下降越明显，高频交易表慎用复杂校验。

真实生产环境中，CHECK 和触发器常共存：前者管简单取值范围（如状态枚举、金额正数），后者管跨表一致性或动态规则。别指望一个机制解决所有问题。