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相关慢语句。
