触发器不是数据验证的首选方案
MySQL 的
TRIGGER能在
INSERT、
UPDATE、
DELETE前后自动执行逻辑，但它**不参与约束检查流程**，也无法阻止违反主键、唯一性或外键的操作——那些会在触发器执行前就报错中断。真正该用触发器的场景是：日志记录、跨表状态同步、生成派生字段（如更新
updated_at），而不是替代
CHECK约束或应用层校验。
MySQL 8.0.16+ 才支持标准 CHECK 约束
旧版本（如 5.7）解析
CHECK子句但完全忽略它，导致你以为加了校验，实际形同虚设。8.0.16 起才真正生效，且支持表达式（如
age >= 0 AND age ）。但要注意：
CHECK约束无法引用其他表数据，也不能调用存储函数（除非是
DETERMINISTIC且有
SQL SECURITY DEFINER） 对已有数据不自动校验，只作用于后续 DML；若建表时数据已违规，语句会直接失败 错误信息统一为
Check constraint 'xxx' is violated.，不提示具体哪条规则失败
触发器中抛出错误必须用 SIGNAL
想在触发器里做自定义校验并中断操作，不能靠
SELECT 1/0或空语句，必须显式
SIGNAL。否则 MySQL 会静默忽略逻辑，甚至让脏数据入库。例如：
DELIMITER $$
CREATE TRIGGER check_email_format
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
IF NEW.email NOT REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid email format';
END IF;
END$$
DELIMITER ;
注意：
SQLSTATE '45000'是用户自定义错误的标准码；
MESSAGE_TEXT内容会出现在客户端报错中，但不会被 MySQL 自动翻译成多语言。
应用层 + 数据库层校验要分清职责
数据库层适合强一致性保障：非空、唯一、外键、数值范围、格式正则（用
CHECK或
TRIGGER + SIGNAL）。但业务规则（如“VIP 用户下单金额不能低于 100 元”）应放在应用层，原因很实在： 触发器无法读取 session 变量或当前登录用户角色 复杂逻辑会让触发器难以测试和调试，出问题时排查路径长（SQL 日志 → 触发器代码 → 表变更链） 批量导入（
LOAD DATA INFILE）默认禁用触发器，容易绕过校验 主从复制中触发器行为可能不一致（尤其使用
ROW格式时，从库不重放触发器）
最易被忽略的一点：很多团队给触发器加了校验，却忘了在 ORM 或迁移脚本里同步维护——表结构改了，触发器没更新，校验就失效了。
