优先用约束——只要它能解决你的问题；约束轻量高效如“交通信号灯”，触发器灵活但有开销如“交警执法”；MySQL 8.0+ 支持 CHECK 后，90% 校验无需触发器；仅跨表逻辑、动态计算等约束无法覆盖时才用触发器。
触发器和约束，谁该先用？
优先用约束——只要它能解决你的问题。约束是数据库内建的“交通信号灯”，轻量、高效、声明式；触发器则是“交警现场执法”，灵活但有开销。MySQL 8.0+ 支持 CHECK 约束后，90% 的业务校验（如 age >= 0、status IN ('active','inactive')）已无需触发器。
什么情况下必须用触发器？
当校验或动作涉及跨表逻辑、动态计算、或无法用 SQL 表达式静态描述时，约束就无能为力了。比如：
- 插入订单前，检查客户剩余信用额度是否足够（需查
customers.credit_limit和orders.total_amount） - 更新商品库存后，自动向
inventory_log表写入变更记录（含操作人、时间戳等上下文） - 删除用户时，级联清除其在 5 张关联表中的记录（外键
ON DELETE CASCADE只支持单层，多表需触发器）
常见踩坑：触发器不是约束的“升级版”
很多人误以为“触发器更强大，所以更可靠”，结果掉进性能和维护陷阱：
-
BEFORE INSERT触发器里执行SELECT ... FOR UPDATE可能引发死锁，而UNIQUE约束不会 - 触发器逻辑藏在数据库里，应用层看不到，调试困难；约束定义直接写在
CREATE TABLE语句中，一目了然 - InnoDB 中，触发器执行会加额外行锁，高并发写入时比纯约束慢 2–3 倍（实测 TPCC 场景）
- 触发器不参与查询优化器决策，而主键/唯一约束自动创建索引，能加速
WHERE和JOIN
实际协作建议：约束兜底 + 触发器补位
一个健壮的数据校验方案往往是分层的：
- 用
NOT NULL、UNIQUE、FOREIGN KEY和CHECK拦住 80% 的非法输入（快、稳、可审计） - 用触发器处理剩下 20% 的复杂场景，但务必加注释说明“为什么不能用约束”
- 避免在触发器里调用存储过程或外部服务——这会让事务不可控，也违背 ACID
- 所有触发器必须带明确命名（如
tr_orders_before_insert_credit_check），否则information_schema.TRIGGERS里查起来像解谜
真正难的不是写触发器，而是判断“这个逻辑到底该不该放进去”。多数时候，翻翻 CREATE TABLE 语句，把 CHECK 写全，就已经解决了大半问题。
