sql触发器性能问题主因是执行模型与场景错配：行级触发器在批量操作中被高频调用、轻量逻辑嵌入重操作、忽略其共享主事务上下文；应改用语句级触发器并确保查询字段有合适索引。
SQL触发器性能问题大多不是语法写错，而是执行模型和使用场景不匹配导致的——行级触发器被当成“批量处理器”用，轻量逻辑被塞进重操作里，或者根本没意识到它共享主事务上下文。
行级触发器在批量操作中被调用上万次
MySQL/PostgreSQL/SQL Server 默认 FOR EACH ROW，一次 UPDATE ... WHERE id IN (1,2,...,10000) 就会触发函数 10000 次。每次调用都有独立上下文开销，哪怕函数体只有一行 INSERT INTO log，总耗时也远超预期。
- 实测：单行
INSERT触发器平均耗时 0.8ms；1000 行批量插入 → 总耗时常突破 1.2s（非线性增长，含锁竞争） - 别依赖“逻辑简单就没事”——上下文切换、内存分配、计划缓存查找本身就有成本
- 改用
FOR EACH STATEMENT+NEW TABLE（PostgreSQL 10+）或INSERTED表（SQL Server）做集合操作，调用次数从 N 降到 1
触发器内查大表没走索引
最常见也最容易漏掉的问题：SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id，而 orders.user_id 没索引。触发器一执行，就是全表扫描，且每次调用都扫一遍。
- 用
EXPLAIN直接跑触发器里的 SQL，看type是不是ALL或index - WHERE 条件字段必须有索引；复合查询（如
status = 'paid' AND created_at > NOW() - INTERVAL 1 DAY）优先建(status, created_at)复合索引 - 避免在索引列上用函数：
WHERE DATE(created_at) = '2026-08-04'会让索引失效，改成created_at >= '2026-08-04' AND created_at
嵌套触发器与递归调用
订单更新触发库存变更，库存变更又触发审计日志，审计日志再触发通知表 —— 这种链式激活在高并发下极易死锁或超时。SQL Server 测试显示，100 行批量更新嵌套触发时，deadlock encountered 发生率超 23%。
- 禁用嵌套是最快止损方式：
EXEC sp_configure 'nested triggers', 0; RECONFIGURE;（SQL Server） - MySQL 没全局开关，只能靠代码规避：不在触发器里直接
UPDATE其他带触发器的表 - 检查是否存在环形依赖（A→B→C→A），这种结构在压力下必然崩
把触发器当应用层逻辑容器
在 AFTER INSERT 里调用存储过程发邮件、写外部日志表、实时聚合统计 —— 这些操作本不该在事务内完成，却硬塞进触发器，结果是主事务响应变慢、锁持有时间拉长、错误回滚范围失控。
- 触发器只该做三件事：校验（
CHECK级别）、标记（如updated_at）、轻量衍生写入（如审计日志，且日志表必须有索引+分区） - 发通知、更新缓存、计算汇总值 → 改用 binlog + Kafka / Canal / logical decoding 异步消费
- 原生机制能替代的，就别手写：比如
ON UPDATE CURRENT_TIMESTAMP比触发器快 3–5 倍，且批量优化友好
真正卡住系统的，往往不是某条 SQL 写得有多差，而是没意识到触发器的执行粒度、事务边界和索引依赖这三点——它们共同决定了“一行慢”会不会变成“全表堵”。
