触发器适用于强一致性且逻辑简单的业务约束，如订单更新同步客户时间、删用户前校验订单、敏感字段审计日志；禁用于跨库操作、复杂计算、需返回结果或替代外键等场景。
SQL 触发器不是万能的“自动工具”，用对了能保障数据一致性，用错了可能拖垮性能甚至引发死锁。 面试中常考的不是语法默写，而是你是否理解它在真实系统中的定位、边界和代价。
触发器最该用在哪？——聚焦不可绕过的业务强约束
触发器的价值在于拦截那些应用层难以统一控制、又必须实时生效的数据变更。比如：
- 订单表更新时，自动同步更新客户表的“最近下单时间”字段（避免应用每次都要手动维护）
- 删除用户前，强制检查其名下是否有未完成订单（防止级联删除遗漏业务逻辑）
- 审计日志表自动记录敏感字段（如工资、密码哈希）被修改的旧值、新值、操作人（应用层可能跳过日志）
关键点：这些逻辑必须在事务内原子执行，且不能依赖外部服务或异步机制。
哪些场景坚决不用触发器？——避开高频坑点
以下情况优先选其他方案，硬上触发器等于埋雷：
- 跨库 / 跨服务操作 ：触发器无法调用 HTTP 接口或写其他数据库，强行用链接服务器或扩展函数会严重破坏可维护性
- 复杂计算或大量数据扫描 ：比如在 INSERT 后触发一个全表 SUM 统计，会导致写入变慢、锁表时间延长
- 需要返回结果给应用层 ：触发器不能直接返回值，若业务需要“插入成功后返回生成的流水号”，应改用存储过程或应用层处理
- 替代外键或唯一约束 ：用触发器模拟级联更新或唯一校验，性能差且易出错，原生约束更可靠
面试官最爱问的风险点——你得说出具体后果
别只说“影响性能”，要讲清链路和现象：
- 隐式递归 ：A 表触发器更新 B 表，B 表触发器又更新 A 表 → 触发器嵌套超限报错（SQL Server 默认最多 32 层），MySQL 需 SET SESSION sql_mode=’NO_ENGINE_SUBSTITUTION’ 才允许，但极易失控
- 事务膨胀 ：一个 INSERT 触发 10 次 UPDATE，每条 UPDATE 又带自己的索引维护 → 单条语句实际产生上百页 IO，长事务阻塞备份和 DDL
- 调试黑洞 ：错误发生在触发器内，堆栈不显示应用调用路径，日志里只有“INSERT 失败”，排查要翻源码 + 开 Profiler 跟踪
- 迁移灾难 ：导出表结构时容易漏掉触发器定义，新环境没触发器导致数据不一致，而问题可能几周后才暴露
替代方案不是非此即彼——分层选择更稳妥
真实项目中，触发器只是工具箱里的一把螺丝刀：
- 强一致性要求 + 简单逻辑 → 触发器（如状态机流转校验）
- 高吞吐写入 + 异步响应 → 消息队列（如 Kafka）+ 消费端处理
- 复杂规则 + 多系统协同 → 应用层领域服务编排（用 Saga 模式保证最终一致）
- 历史数据修正 + 批量操作 → 定时 ETL 任务（避免干扰在线事务）
真正高级的回答，是能根据 QPS、一致性等级、运维能力，给出取舍依据，而不是背诵“触发器的优点缺点”。
