MySQL5.7触发器模拟实现CHECK约束

在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 操作都会被拖慢。
• 比较稳妥的做法是，把这种计数逻辑放到应用层去维护缓存，或者通过唯一组合键配合应用层预判来解决。在触发器里做复杂查询，收益低，风险高。

话说回来，真正需要在数据库层面做这种强一致性校验的场景其实很少，很多时候是设计过度了。遇到这种需求，先冷静想想：应用层是不是真搞不定？确认了再考虑要不要在触发器里折腾。