SQL 触发器确实会带来性能开销，但影响程度取决于设计方式、数据量和执行逻辑的复杂度。关键不是“用不用”，而是“怎么用才不拖慢系统”。
触发器在哪个环节消耗资源？
触发器在 DML 语句（INSERT/UPDATE/DELETE）执行过程中同步运行，属于事务的一部分：
- 解析与编译开销：首次执行时需生成执行计划，频繁修改表结构或触发器定义会反复重编译；
- 行级锁延长：触发器内访问其他表可能扩大锁范围或延长持有时间，加剧阻塞；
- 事务膨胀：一个 INSERT 触发 100 行 UPDATE，实际变成 101 个写操作，日志量、回滚段压力同步上升；
- 隐式递归风险：比如 UPDATE 触发器里再 UPDATE 同一张表，可能触发自身（除非禁用嵌套），造成不可控的链式执行。
哪些写法会让触发器明显变慢？
以下操作在触发器中应尽量避免：
- 循环处理多行数据：SQL Server 的 AFTER 触发器中用 CURSOR 遍历 inserted/deleted 表；MySQL 中用 WHILE 模拟循环；
- 跨库 / 远程查询：触发器里调用链接服务器、调用外部 API（即使封装成存储过程）；
- 复杂计算或字符串拼接：尤其在高并发插入场景下，CPU 成为瓶颈；
- 未加 WHERE 条件的 UPDATE/DELETE：例如“UPDATE logs SET status=1”而不限定时间范围，扫全表更新。
如何低成本实现触发器目标？
多数业务逻辑其实有更轻量的替代方案：
- 改用应用层校验 + 异步任务：如订单状态变更后发 MQ 消息，由消费者服务写审计日志或同步库存，不卡主事务；
- 用计算列或索引视图替代简单派生字段：避免每次 INSERT 都算一次 MD5 或 CONCAT；
- 批量操作绕过触发器 ：SQL Server 可用DISABLE TRIGGER 临时关闭，MySQL 可设SQL_LOG_BIN=0（仅限从库维护）；
- 合并逻辑到主 SQL：把原本放在 UPDATE 触发器里的计数更新，改成“UPDATE t SET cnt = cnt + 1 WHERE id = @id”，一行搞定。
必须用触发器时的优化底线
若合规或历史原因无法移除，至少守住这几点：
- 只响应必要事件：用 IF 判断是否真有字段变更（如IF UPDATE(status)），避免无意义执行；
- 所有查询走索引：触发器内涉及的 JOIN、WHERE 字段必须有对应索引，explain 确认没全表扫描；
- 控制影响行数：对大表操作，考虑分批提交（如每次 1000 行），避免单次触发器处理数万行；
- 监控实际耗时：SQL Server 查sys.dm_exec_trigger_stats，MySQL 开启 slow log 捕获 trigger 相关慢语句。
