触发器适合做数据一致性兜底，不适合承载业务逻辑；应仅用于同一事务内的数据完整性约束（如更新时间戳、校验负值），禁止调用外部服务或产生不可回滚副作用。
触发器适合做数据一致性兜底，不适合承载业务逻辑
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 行触发器定义。
