触发器不是Check约束的升级版而是兜底方案，应优先用BEFORE触发器模拟约束行为，避免跨表SELECT、函数包裹字段等性能陷阱，校验逻辑须用纯SQL表达式实现。
Check约束做不到的复杂校验，触发器不是“升级版”，而是“兜底方案”——它更灵活，但默认更重。真要替代Check约束，核心不是“怎么写触发器”，而是“怎么让触发器不拖慢INSERT/UPDATE”。
BEFORE触发器比AFTER更适合替代Check约束
Check约束在语句执行前就完成校验，失败直接报错、不进事务；AFTER触发器则必须等数据已写入才跑，出错时还得回滚，开销翻倍。BEFORE触发器能提前拦截，行为更接近原生约束。
- MySQL中用
BEFORE INSERT或BEFORE UPDATE，在NEW字段上做判断，必要时用SIGNAL SQLSTATE '45000'抛出自定义错误 - PostgreSQL支持
WHEN子句，可把条件提前过滤，避免无谓进入触发体：CREATE TRIGGER ... BEFORE UPDATE ON orders FOR EACH ROW WHEN (NEW.status = 'shipped') EXECUTE FUNCTION check_shipment_validity() - SQL Server里
INSTEAD OF也可用于视图层拦截，但别在基表上滥用——它绕过原操作，容易破坏应用预期
跨表校验必须避开SELECT子查询
常见错误是：在BEFORE INSERT里写SELECT COUNT(*) FROM accounts WHERE user_id = NEW.user_id AND status = 'active'。这会引发额外锁、IO和可能的死锁。
- 改用
EXISTS代替COUNT(*)，减少扫描量 - 确保被查字段（如
user_id,status）有联合索引，且顺序匹配查询条件 - 如果校验逻辑本身依赖聚合（比如“用户当日下单不能超3单”），别在触发器里实时算——改用冗余字段+应用层预检，或异步更新计数缓存表
触发器里禁止调用存储过程或自定义函数
MySQL触发器不支持显式事务控制，一旦CALL validate_order_rules(NEW.id)内部出错或超时，整个DML就卡住。SQL Server或PostgreSQL虽支持，但函数内若含游标、循环或远程调用，性能会断崖下跌。
- 所有校验逻辑必须写成纯SQL表达式：用
CASE WHEN、窗口函数、COALESCE等原生能力拼装 - 避免
DATE_FORMAT(NOW(), '%Y-%m')这类函数包裹字段做判断——它会让索引失效；改用范围比较：NEW.created_at >= '2026-09-01' AND NEW.created_at - MySQL 8.0.22+ 支持部分标量函数内联，但必须显式声明
DETERMINISTIC，否则仍可能重复计算
真正该用触发器的场景其实很少
多数所谓“复杂约束”，本质是业务规则下沉过深。比如“订单金额不能低于用户信用额度”，这不该由数据库硬校验，而应由风控服务在下单前返回结果。触发器只适合那些无法绕过DB写入路径、且必须强一致的极少数环节。
- 优先用MySQL 8.0.16+的
CHECK约束，支持布尔表达式和引用其他列 - 对历史数据兼容性要求高的场景，可用
BEFORE触发器 + 应用层幂等标记，避免重复校验 - 一旦触发器开始出现
LOCK WAIT TIMEOUT EXCEEDED或慢日志里频繁出现TRIGGER关键词，说明它已经成了性能瓶颈，该立刻下线并改用CDC+应用监听
最常被忽略的一点：触发器没有“调试入口”。它静默运行，出错只报一行ERROR 1644，连上下文都看不到。上线前务必用SELECT模拟NEW/OLD值手动验证逻辑，别依赖“应该没问题”。
