触发器适合做数据一致性兜底，不适合承载业务逻辑
MySQL 触发器本质是数据库层的自动响应机制，
BEFORE INSERT、
AFTER UPDATE这类操作只能保证「同一事务内」的数据约束生效。比如强制更新
updated_at字段、校验金额不能为负、防止误删核心配置行——这些属于数据完整性范畴，用触发器合理且高效。
但一旦涉及调用外部服务、发消息、聚合统计、状态机流转，就该立刻停手。触发器里不能执行
SLEEP()、不能发 HTTP 请求、无法回滚外部副作用，更没法做重试或日志追踪。强行塞业务逻辑，只会让故障排查变成「不知道哪条 SQL 悄悄触发了哪个隐藏函数」。
应用层逻辑更可控，但要注意事务边界和重复执行风险
把校验、计算、通知等步骤放在应用代码里（如 Python 的 Django signal、Go 的 repository 层、Java 的 service 方法），好处是调试方便、可观测性强、能用完整生态（Redis 锁、MQ、OpenTelemetry）。但必须明确两点：
所有数据库变更必须包裹在显式事务中，START TRANSACTION到
COMMIT之间不能穿插异步操作 避免「先写 DB 再发 MQ」这种模式——DB 提交成功但 MQ 发送失败，会导致状态不一致；应改用本地消息表 + 定时扫表，或用
XID关联的分布式事务框架 如果用 ORM 的 hook（如 SQLAlchemy
@event.listens_for），注意它只在 ORM 层触发，绕过 raw SQL 就会失效
混合方案常见陷阱：触发器改了数据，应用层没感知
典型翻车场景：应用层读取一条记录后做判断，同时触发器在
BEFORE UPDATE中悄悄修改了其中某个字段（比如把
status从
'pending'改成
'validated'），但应用代码仍按原始值继续执行，结果逻辑错乱。
这类问题极难复现，因为取决于执行时机和隔离级别。规避方式只有两个：
触发器只做「不可见」的维护型操作：如自增版本号version = version + 1、填充审计字段
created_by应用层所有关键判断，必须基于
SELECT ... FOR UPDATE重读最新数据，而不是依赖之前缓存的值
性能与可维护性的真实权衡点
单条记录操作下，触发器开销几乎可忽略；但批量导入时（如
LOAD DATA INFILE或百万级
INSERT ... SELECT），每个行都会执行触发器逻辑，CPU 和锁竞争会陡增。此时应用层分批控制节奏反而更稳。
另一个隐形成本是部署：触发器属于数据库 schema 的一部分，但多数 CI/CD 流程只管应用代码和 SQL migration，容易漏掉触发器变更，导致预发环境和生产环境行为不一致。上线前务必确认
SHOW CREATE TRIGGER `xxx`输出已纳入版本管理。
真正难的从来不是语法对不对，而是下次有人要查「为什么订单状态突然变成已取消」时，得翻三处地方：应用日志、binlog、还有那个藏在
information_schema.TRIGGERS里的 200 行触发器定义。
