check约束在mysql 8.0.16+才真正生效，需同时满足版本≥8.0.16、sql模式含strict_trans_tables、innodb引擎、row_format=dynamic及数据合规，否则插入非法值不报错。
CHECK约束在MySQL 8.0中不是“写了就生效”，必须同时满足版本、模式、引擎、数据四重条件，否则插入非法值照样成功。
确认 MySQL 版本是否真正支持 CHECK
仅靠 SELECT @@version 返回 8.0.x 不够——必须是 8.0.16 或更高（如 8.0.33、8.4.0）。8.0.15 及更早的 8.0.x 版本虽解析语法，但完全忽略校验。
- 执行
INSERT INTO t VALUES (-1)测试：建表时加了CHECK (x > 0)，若不报错Check constraint 't_chk_1' is violated，说明未生效 - 云数据库（如阿里云 RDS）还需检查实例参数
check_constraint_enforced是否为ON - 本地部署需确认
information_schema.TABLE_CONSTRAINTS中对应约束的ENFORCED = 'YES'
让 CHECK 真正起作用的最小必要配置
即使版本达标，CHECK 仍可能静默失效。关键在于运行上下文：
- SQL 模式必须包含
STRICT_TRANS_TABLES（不能只有NO_ZERO_DATE等宽松项），用SELECT @@sql_mode验证 - 存储引擎必须是
InnoDB；MyISAM会直接忽略 CHECK，且不报错 - 表格式推荐
ROW_FORMAT=DYNAMIC（REDUNDANT在 8.0+ 行为异常，部分 CHECK 不触发） - 建表后执行
SHOW CREATE TABLE t，输出中必须明确出现CHECK子句——若缺失，说明被语法兼容层过滤掉了
列级 vs 表级 CHECK 的实际选择
两者语义一致，但适用场景不同，选错会导致功能受限或维护困难：
- 列级写法（如
status VARCHAR(20) CHECK (status IN ('pending','paid'))）只能引用当前列，适合单字段简单规则，命名由 MySQL 自动生成（如t_chk_1），后期难定位 - 表级写法（如
CONSTRAINT chk_ship_time CHECK (ship_time >= order_time OR ship_time IS NULL)）支持跨列逻辑，且可显式命名，便于后续ALTER TABLE ... DROP CHECK chk_ship_time - 禁止在 CHECK 中使用非确定性函数：
NOW()、CURRENT_DATE()、UUID()会直接报错ERROR 3816
ALTER TABLE 添加 CHECK 时的典型失败点
对已有表加 CHECK 是高危操作，失败不是语法问题，而是数据合规性问题：
- MySQL 会自动扫描全表验证存量数据是否满足新约束；只要有一行不满足（如
email字段含空值，而新约束是email LIKE '%@%'），就会报ERROR 3819 (HY000): Check constraint 'xxx' is violated - 删除约束必须用准确名称：
ALTER TABLE t DROP CHECK chk_name（不是DROP CONSTRAINT），名称可通过SHOW CREATE TABLE t或错误信息末尾获取 - 如需灰度启用（比如先校验不阻断），可用
ALTER TABLE t ALTER CHECK chk_name NOT ENFORCED，但这个状态极易被遗忘，导致约束长期失效
最常被忽略的一点：CHECK 对 NULL 的处理遵循 SQL 标准——当表达式结果为 UNKNOWN（如 NULL >= 10）时，约束不触发，即不报错。这意味着业务上需要“非空且大于零”的字段，不能只靠 CHECK (x > 0)，还得配合 NOT NULL 或 DEFAULT 显式控制空值路径。
