MySQL 8.0.16起CHECK约束才真正生效；此前版本语法通过但不校验。列级CHECK适用于单字段范围校验，如age TINYINT UNSIGNED CHECK (age BETWEEN 0 AND 150)。
确认 MySQL 版本是否真支持 CHECK
MySQL 8.0 的 CHECK 约束在 8.0.16 及之后才真正生效；8.0.0 到 8.0.15 虽然语法能通过，但插入非法值完全不报错——你写的 CHECK (age >= 0) 就像没写一样。
别只看 SELECT @@version 返回 “8.0.x”，必须确认小版本号 ≥ 16。更可靠的做法是实测：
- 建表：
CREATE TABLE t (x INT, CONSTRAINT chk_x CHECK (x > 0)); - 插入：
INSERT INTO t VALUES (-1); - 如果报错
Check constraint 'chk_x' is violated.（错误号 3819），说明生效；否则就是“假支持”
用列级还是表级 CHECK 写年龄范围
单字段范围校验（如年龄 0–150）用列级最简洁，但必须注意：它只能引用当前列，且不能重复加多个列级 CHECK。
示例（列级）：age TINYINT UNSIGNED CHECK (age BETWEEN 0 AND 150)
示例（表级，推荐显式命名）：CONSTRAINT chk_age_valid CHECK (age >= 0 AND age
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
区别不只是写法：
- 列级约束名由 MySQL 自动生成（如
t_chk_1），后续删改困难 - 表级可自由命名，也方便后期用
ALTER TABLE DROP CHECK chk_age_valid精准删除 - 若未来要扩展为跨列逻辑（比如“入职年龄 ≤ 当前年龄”），只有表级能平滑升级
为什么 INSERT 还是成功了？常见失效原因
即使版本够新、语法正确，CHECK 仍可能被绕过。核心原因不是约束写错了，而是环境没配对：
- SQL 模式不含
STRICT_TRANS_TABLES：执行SELECT @@sql_mode，若结果里没有它，CHECK 很可能被静默忽略 - 引擎不是 InnoDB：
MyISAM完全不支持 CHECK，建表时不会报错，但SHOW CREATE TABLE里也看不到 CHECK 子句 - 表格式非
DYNAMIC：某些老迁移表用REDUNDANT，在 8.0+ 中 CHECK 行为异常 - 已有数据不满足新约束：用
ALTER TABLE ADD CHECK时，MySQL 会先校验全表数据，不满足就直接报ERROR 3819
避免踩坑的实操建议
CHECK 不是“写了就完事”的功能，几个关键点容易被忽略：
- 禁止在表达式中用
NOW()、CURRENT_DATE()、RAND()等非确定性函数，会直接报错ERROR 3816 -
NULL参与比较时结果为UNKNOWN，约束不触发（即不报错），这是 SQL 标准行为，不是 bug - 想灰度上线？用
NOT ENFORCED：ADD CONSTRAINT chk_email CHECK (email REGEXP '...') NOT ENFORCED，后续再ALTER CHECK chk_email ENFORCED - 云数据库（如阿里云 RDS）需单独确认参数
check_constraint_enforced=ON，默认可能关着
最常被漏掉的是：约束名在库内必须唯一，且删除时语法是 DROP CHECK 约束名，不是 DROP CONSTRAINT——输错一个字就执行失败。
