触发器让线上排查变成噩梦，因其运行在事务内部、不暴露调用链、无标准日志埋点，APM抓不到；SHOW PROCESSLIST只显示主语句，不体现嵌套逻辑；慢SQL告警和分布式追踪均无法覆盖触发器内耗时与错误。

触发器不是业务逻辑的“自动补丁”，用多了反而让系统更难维护、更慢、更容易出错——它只适合极少数数据库层必须兜底的场景，比如审计日志写入或时间戳自动生成。

触发器为什么会让线上排查变成噩梦

它运行在事务内部、不暴露调用链、没有标准日志埋点，APM 工具完全抓不到。你看到 UPDATE orders 耗时 800ms，但实际 720ms 花在触发器里查 sku_info 表且没走索引；SHOW PROCESSLIST 只显示主语句，不会告诉你背后还嵌套了三层触发逻辑；线上出问题时，得先手动查 INFORMATION_SCHEMA.TRIGGERS，再翻定义，再猜执行路径。

• 慢 SQL 告警只报主语句，不体现触发器内耗时
• 分布式追踪（如 OpenTelemetry）无法采集触发器内操作
• 错误堆栈不包含触发器上下文，THROW 或 SIGNAL 报错信息模糊，常被误当成应用层失败

批量操作下性能断崖式下跌

MySQL/PostgreSQL 默认是 FOR EACH ROW，1 万行插入 = 触发器函数被调用 1 万次。哪怕只是往日志表插一条记录，也会产生 1 万次独立 INSERT、1 万次锁竞争、1 万次执行计划解析开销。SQL Server 若未关 RECURSIVE_TRIGGERS，还可能因触发器里更新自身表引发递归上千层。

• 标量写法（如 SELECT @val = amount FROM inserted）在批量场景下只取第一行，其余数据静默失效
• 无法使用 NOLOCK 或并行执行优化，也不能复用执行计划缓存
• 物化视图、增量聚合、定时任务等替代方案天然支持批处理，而触发器天生反批量

真正该用什么替代触发器

不是“要不要加逻辑”，而是“在哪一层、以什么方式加”。核心原则：能用原生机制的，绝不用触发器；能上移到应用层的，绝不留在数据库里。

• 时间戳、UUID、默认值 → 直接用 DEFAULT CURRENT_TIMESTAMP 或 DEFAULT gen_random_uuid()
• 字段校验（邮箱格式、金额非负）→ 放在应用层拦截，失败直接返回，避免无谓事务开销
• 跨表一致性（如下单扣库存）→ 由统一 SDK 或 DAO 在单事务中完成，所有写入路径收口
• 审计日志 → 若必须数据库级兜底，用 AFTER INSERT/UPDATE/DELETE 写轻量日志表；否则改用 CDC（如 Debezium）或应用层事件总线
• 统计类字段（部门总薪资）→ 改用定时任务 + last_modified 过滤增量更新，或用物化视图自动刷新

最易被忽略的一点：触发器只对标准 DML 生效。ETL 工具用 COPY 或 BULK INSERT 加载数据时，默认跳过触发器；DBA 手动执行 UPDATE 绕过业务代码；跨库同步产生的写入完全不经过源库触发器——这些“绕过路径”一旦存在，所谓“强一致”就立刻崩塌。