mysql 8.0.16+才真正执行check约束；此前版本（如5.7、8.0.15）仅语法解析但不校验，insert非法值不报错，show create table也看不到约束定义，且必须使用innodb引擎。
MySQL 8.0.16+ 才真正执行 CHECK 约束
低于 8.0.16 的版本（比如 8.0.15 或 5.7）写 CHECK 只是语法通过，实际不拦截任何非法数据。先运行 SELECT VERSION(); 确认版本，否则后面所有约束都是摆设。
常见错误现象：建表时写了 CHECK (age >= 0)，却能成功插入 -5；查 SHOW CREATE TABLE t; 发现约束根本没出现在输出里——这就是版本太低的典型表现。
- 必须用
ENGINE=InnoDB：MyISAM 完全忽略CHECK，哪怕版本够新 - 表达式必须返回布尔值：
TRUE或UNKNOWN（如含NULL运算）允许写入，FALSE直接报错Check constraint 'xxx' is violated. - 命名别超 64 字符，且大小写敏感；重复名会报错，建议显式命名，比如
CONSTRAINT chk_phone_format CHECK (phone REGEXP '^1[3-9][0-9]{9}$')
哪些校验适合用 CHECK，哪些必须用触发器
CHECK 只能做单表、无外部依赖的静态判断。它不是“轻量版触发器”，而是两类不同工具：前者声明式、引擎层拦截；后者过程式、可跨表/会话。
能直接用 CHECK 的典型场景：
- 数值范围：
age CHECK (age BETWEEN 0 AND 150) - 枚举限制：
status CHECK (status IN ('active', 'inactive')) - 非空组合：
CHECK (email IS NOT NULL OR phone IS NOT NULL) - 跨列逻辑：
discount_price CHECK (discount_price - JSON 结构：
metadata CHECK (JSON_VALID(metadata) AND JSON_TYPE(metadata) = 'OBJECT')
必须用触发器的场景（CHECK 做不了）：
- 查另一张表，比如插入订单前验证客户余额：
SELECT credit_limit FROM customers WHERE id = NEW.customer_id - 依赖会话变量或当前用户：
NEW.created_by = USER()或@tenant_id - 需要写日志表并记录 IP、时间戳等无法从
NEW/OLD直接获取的信息
CHAR_LENGTH() 和 LENGTH() 别混用
字符串长度校验写成 CHECK (LENGTH(phone) = 11) 在中文或 emoji 场景下会失效——因为 LENGTH() 返回字节数，CHAR_LENGTH() 才是字符数。UTF8MB4 下一个 emoji 占 4 字节，但只是 1 个字符。
正确写法示例：
phone CHECK (CHAR_LENGTH(phone) = 11 AND phone REGEXP '^1[3-9][0-9]{9}$')username CHECK (CHAR_LENGTH(username) BETWEEN 2 AND 20)
另外注意：自定义函数必须声明为 DETERMINISTIC，否则 MySQL 拒绝解析 CHECK 表达式。
ALTER TABLE 添加 CHECK 时默认校验存量数据
执行 ALTER TABLE t ADD CONSTRAINT chk_xxx CHECK (expr); 时，MySQL 会扫描全表检查现有数据是否满足条件。如果不满足，操作直接失败，报错类似 Check constraint 'chk_xxx' is violated.
这时有两个选择：
- 先清理或修正脏数据，再加约束
- 加
NOT ENFORCED临时跳过校验：ADD CONSTRAINT chk_xxx CHECK (expr) NOT ENFORCED，后续再用ALTER TABLE ... ENFORCED启用
别在 AFTER INSERT 触发器里做校验——错误已经写进去了；CHECK 是在数据落盘前拦截，这才是它不可替代的价值点。
容易被忽略的是：ORM 框架（如 SQLAlchemy、MyBatis）不会自动读取或同步数据库里的 CHECK 规则，应用层校验和数据库约束得人工对齐，否则两边逻辑不一致会埋坑。
