mysql check约束在5.7及之前被静默忽略，8.0起支持但需严格模式才生效，且禁止非确定性函数；添加约束时会校验全表数据，违规则报错。
CHECK约束在MySQL中默认不强制校验，不是你写错了，而是MySQL 8.0之前根本没实现它——直到8.0才开始支持，但仍有大量限制和默认关闭行为。
MySQL 5.7及更早版本：CHECK只是语法摆设
你在CREATE TABLE里写了CHECK (age > 0)，插入-5却成功，不是bug，是设计如此。MySQL 5.7会解析并忽略该子句，不报错也不生效。执行SHOW CREATE TABLE或查information_schema.TABLE_CONSTRAINTS，根本看不到CHECK记录。
- 官方文档明确说明：5.7中CHECK被接受但“silently ignored”
- 升级到8.0前，任何依赖CHECK做数据兜底的逻辑都实际失效
- 别用
SELECT去验证约束是否存在——它压根没存进元数据
MySQL 8.0+ CHECK仍可能不触发：strict mode没开
即使用了8.0+，CHECK默认也只在严格SQL模式下才抛错。否则，违反约束时MySQL可能只发warning，甚至静默接受（尤其用INSERT IGNORE或REPLACE时）。
- 必须启用
STRICT_TRANS_TABLES或STRICT_ALL_TABLES，例如：SET sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'; - 检查当前模式：
SELECT @@sql_mode;，确认含STRICT_*字样 - 仅靠
check_constraint_checks=ON（默认就是ON）不够——它只控制约束是否“参与校验”，但不改变错误级别
已有数据导致ALTER TABLE ADD CHECK失败
给已有表加约束时，MySQL会立即扫描全表验证。只要有一行数据不满足条件，整个ALTER TABLE ... ADD CHECK就直接报错ERROR 3819 (HY000): Check constraint is violated，不会部分生效。
- 先定位违规数据：
SELECT * FROM users WHERE age 150; - 修正或清理后再执行
ALTER TABLE，不要指望MySQL自动跳过坏数据 - 如果数据量大且无法清理，考虑用
TRIGGER替代——但注意触发器无法拦截LOAD DATA INFILE等批量操作
CHECK表达式本身被MySQL拒绝：非确定性函数、子查询、复杂逻辑
MySQL 8.0不允许在CHECK中使用CURRENT_DATE()、UUID()、(SELECT ...)或嵌套函数调用，会直接报错ERROR 3816 (HY000)。
- 允许的只有常量、列引用、确定性运算符（
AND/OR/BETWEEN）和内置确定性函数（如ABS()、UPPER()） -
CHECK (email LIKE '%@%')合法；CHECK (email REGEXP '^.+@.+\..+$')也合法（REGEXP是确定性的） - 想校验时间范围？别写
CHECK (created_at ——<code>NOW()是非确定性的，会失败
真正麻烦的从来不是怎么写CHECK，而是它只管写入、不管读取，只拦INSERT/UPDATE、不拦SELECT/DELETE，且永远无法替代应用层参数化查询——哪怕你把CHECK写得再密不透风，只要代码里有一处"WHERE id = " . $_GET['id']，整个防线就塌了。
