在MySQL 5.7里，CHECK约束基本上就是个摆设，写上去不会报错，但也不干活。真要保证数据质量，还得靠触发器来兜底。不过，很多新手在这儿容易踩坑：觉得写个BEFORE INSERT就万事大吉了，结果业务跑起来，一更新数据，妖魔鬼怪全进来了。
核心只有一句：要同时写 BEFORE INSERT 和 BEFORE UPDATE 两个触发器，并且校验失败时，必须直接用 SIGNAL 果断报错，别想着悄悄改个值糊弄过去。
光有 INSERT 触发器，漏洞大得很
不少人表建好，BEFORE INSERT 触发器也配上了，觉得稳了。结果上线没两天，发现 age 字段居然出现了 -5 或者 200 这种离谱值，一查，全是 UPDATE 语句干的“好事”。
原因很简单：
BEFORE INSERT只管插入，对UPDATE根本视而不见。- 业务代码里，尤其是 ORM 框架生成的批量更新，满屏都是
UPDATE ... SET age = ?。 - 缺少
BEFORE UPDATE这个“守门员”，校验逻辑就出现了一个大窟窿，数据一致性就是空谈。
报错要干脆，别搞“静默修改”那一套
我看过不少代码，在触发器里这么写：SET NEW.age = IF(NEW.age BETWEEN 0 AND 150, NEW.age, NULL)。这种写法意味着，当传入非法值时，MySQL 不会告诉你错了，而是悄悄地把值变成 NULL 或者默认值。这种“静默截断”很多时候是违背业务初衷的——比如年龄字段，你本来就不允许为空，结果它默默给你置空了，后患无穷。
最干净利落的方式，就是用 SIGNAL 语句让操作直接中断：
IF NEW.age < 0 OR NEW.age > 150 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'age must be between 0 and 150'; END IF;
这里 SQLSTATE '45000' 是通用的自定义异常码，后面的 MESSAGE_TEXT 会被客户端应用直接捕获到，远比用自定义变量配合 SELECT 抛错要来得干净和可靠。
触发器里的 NEW 值，不是你传进来的那个字面量
要理解触发器，必须明白一点：在执行到触发器主体时，NEW 字段已经是 MySQL 经过多重处理（默认值、表达式、自增等）后的最终“行镜像”。
- 举个例子：如果表定义里有
age INT DEFAULT 18，那么插入时即使没写 age 字段，NEW.age也已经带着18这个值了。 - 如果某个字段设了
NOT NULL且无默认值，但你传了个NULL，MySQL 会在触发触发器之前就直接报错（违反 NOT NULL 约束），根本走不到你的校验逻辑里来。 - 所以，一切校验判断都得围绕
NEW.age来做，别妄想还原原始 SQL 语句里的那些值。
跨表校验：小心锁和性能陷阱
有些场景需要跨表做动态限制，比如“同一个 category 下最多只能有 10 条记录”。在触发器里写个 SELECT COUNT(*) 看似解决了问题，实则可能引出大的麻烦。
SELECT COUNT(*) FROM limits WHERE category = NEW.category这种查询默认会加共享锁（S 锁），在并发写入量大的场景下，很容易阻塞其他事务。- 更可怕的是，如果
limits.category字段没索引，每次都要全表扫描，那所有对该表的INSERT和UPDATE操作都会被拖慢。 - 比较稳妥的做法是，把这种计数逻辑放到应用层去维护缓存，或者通过唯一组合键配合应用层预判来解决。在触发器里做复杂查询，收益低，风险高。
话说回来，真正需要在数据库层面做这种强一致性校验的场景其实很少，很多时候是设计过度了。遇到这种需求，先冷静想想：应用层是不是真搞不定？确认了再考虑要不要在触发器里折腾。
