必须用触发器的场景仅限于：该规则对所有写入路径生效、需事务内原子回滚、且不依赖任何外部服务；典型如审计字段强制填充、跨表约束校验、状态流转强校验及不可绕过的操作日志。
绝大多数业务逻辑必须写在应用层，触发器只在极少数“绕不过、等不起、不能错”的场景下才值得启用。
哪些操作真的必须用触发器？
不是“方便就用”，而是“不用就会出事”。只有同时满足三个条件时，才考虑触发器：
- 该规则必须对所有写入路径生效——包括 DBA 直接
UPDATE、ETL 工具批量导入、跨库 CDC 同步、甚至LOAD DATA INFILE - 该操作必须与主 DML 在同一事务中完成且可回滚——比如校验失败时整个
INSERT必须中断，而不是事后告警 - 该逻辑完全不依赖外部服务——不能发 HTTP 请求、不能写 Redis、不能调 Kafka，也不能访问远程数据库链接
典型真需求：
-
BEFORE INSERT强制填充created_at和created_by，禁止应用传入 -
BEFORE UPDATE校验订单状态流转：只允许pending→confirmed，禁止跳转cancelled -
AFTER DELETE向audit_log表插入带OLD.*的完整快照，且日志写入失败时整个DELETE回滚 -
BEFORE INSERT查询另一张表做跨表约束（如客户余额 ≥ 订单金额），CHECK约束做不到，应用层又可能被绕过
哪些看似合理但实际不该用触发器？
这些是高频翻车点，表面省事，实则埋雷：
- 在
AFTER INSERT里调curl或http_post()发通知——MySQL 原生不支持，PostgreSQL 需dblink或pg_net扩展，且无法回滚网络请求 - 用
AFTER UPDATE自动更新统计表（如order_summary.total）——mysqldump --skip-triggers默认不导出触发器，恢复后数据静默不一致 -
BEFORE UPDATE悄悄改status字段，而应用层还按旧值判断分支——在READ COMMITTED隔离级别下，应用 SELECT 可能读不到触发器刚写的值，导致逻辑错乱 - 两个表互建
AFTER INSERT触发器互相写对方——MySQL 报ERROR 1422或堆栈溢出，错误堆栈里根本看不出是哪个触发器引发的
怎么快速判断该放哪一层？
别纠结“能不能”，直接问三句话：
- 这个规则，DBA 手工执行
UPDATE users SET status='deleted' WHERE id=123时，会不会被跳过？ - 如果校验失败，你希望整个语句失败并回滚，还是记录日志后继续执行？
- 这个逻辑里有没有
INSERT INTO kafka_offsets、CALL notify_service()、SELECT ... FROM remote_db.table这类外部依赖？
只要任一答案是“不会被跳过”“必须回滚”“完全没有外部依赖”，才进触发器候选池；否则一律放应用层。
混合使用时最危险的细节
触发器和应用层共存时，真正的问题不是“谁来写”，而是“谁先看到”：
- 应用层在事务里先
UPDATE订单状态，触发器再UPDATE库存——若库存不足，触发器抛异常，整个事务回滚，但应用层已发出去的 MQ 消息无法撤回 - 触发器写了
updated_at，应用层又自己算一遍时间再UPDATE——竞态下可能覆盖触发器写入的值 - 同一个字段，触发器做格式化（如转小写），应用层又做校验（如正则匹配）——两者逻辑不一致时，错误发生在哪一层都难定位
复杂点在于：触发器执行时机不可见、调试不可断点、日志分散在数据库 slow log 和应用日志里。一旦出问题，第一反应往往是“是不是应用代码漏了”，而真实原因藏在 information_schema.TRIGGERS 里没人查。
