mysql 8.0.16前check约束无效，须用before insert/update触发器校验；before可拦截非法数据，after无法阻止写入；编写时需注意变量声明位置、delimiter修改、null判断及错误码规范。
MySQL 8.0.16 之前版本的 CHECK 约束形同虚设，真正能落地的字段级、跨表级、业务逻辑级校验，只能靠 BEFORE INSERT 和 BEFORE UPDATE 触发器来兜底。
为什么必须用 BEFORE 而不是 AFTER？
因为校验的目标是“阻止非法数据写入”，而不是事后补救。AFTER 触发器执行时，DML 已提交，哪怕你 SIGNAL 抛错，数据也已落库（除非显式回滚，但触发器里不能直接控制事务）。而 BEFORE 触发器在语句执行前介入，天然具备拦截能力。
-
BEFORE INSERT：可检查NEW.column值，比如手机号格式、年龄范围、枚举合法性 -
BEFORE UPDATE：可对比OLD.column和NEW.column，实现状态流转控制（如“订单只能从 pending → shipped，不可逆”） - 别写
BEFORE DELETE来做“禁止删除”——应用层更合适；真要拦，用FOREIGN KEY或权限控制更安全
怎么写一个不踩坑的校验触发器？
核心是三件事：访问值、判断条件、抛错中断。最容易出错的是变量声明位置、DELIMITER 忘改、以及忽略 NULL 边界情况。
- 所有变量声明（如
DECLARE msg VARCHAR(100)）必须放在BEGIN后第一行，否则报语法错误 - 务必用
DELIMITER //临时改结束符，否则 MySQL 会把第一个分号当成整个CREATE TRIGGER语句的结尾 - 对可能为
NULL的字段做校验时，要用IS NULL或IS NOT NULL，别用= NULL（永远返回 false） - 错误码推荐用
'45000'（标准未定义异常），避免自定义 SQLSTATE 引起兼容问题
示例：限制 products 表的 price 必须大于 0 且小于 10000：
DELIMITER //
CREATE TRIGGER chk_price_before_insert
BEFORE INSERT ON products
FOR EACH ROW
BEGIN
IF NEW.price = 10000 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '价格必须在 (0, 10000) 区间内';
END IF;
END//
DELIMITER ;
跨表校验和性能风险怎么平衡？
触发器里允许 SELECT 查询其他表，比如校验用户状态、检查库存余量、验证外键关联是否存在——但这是把双刃剑。
- 每次 INSERT/UPDATE 都触发一次额外查询，高并发下容易成为瓶颈
- 若被查表没加索引，或查询条件没走索引，延迟会明显升高
- 避免在触发器里写复杂 JOIN 或子查询；单表主键/唯一索引查找最安全
- 如果校验逻辑涉及多行或多表聚合（如“用户本月订单总额不能超 5w”），建议改用应用层预检 + 数据库事务兜底，别硬塞进触发器
典型安全写法（查单条状态）：
SELECT status INTO @user_status FROM users WHERE id = NEW.user_id;
这行的前提是 users.id 是主键或有索引，否则就埋雷了。
触发器不是万能的，这些地方它管不了
别指望触发器覆盖所有数据入口。它只响应通过 SQL DML（INSERT/UPDATE/DELETE）发起的操作。
- 批量导入（
LOAD DATA INFILE）默认绕过触发器，需显式加SET sql_log_bin = ON并确认 binlog 格式 - 物理备份恢复、表交换（
ALTER TABLE ... EXCHANGE PARTITION）不触发任何触发器 - 存储过程内部的 DML 会触发，但如果你在过程里用了
INSERT IGNORE或REPLACE，错误可能被吞掉 - 最隐蔽的漏洞：DBA 直接用
mysqldump --skip-triggers导出再导入，触发器就丢了
真正关键的约束，得配合应用层校验 + 定期数据巡检脚本，不能只信触发器那一道闸。
