sql server触发器中用游标会严重拖垮并发性能，因其将批量操作拆为单行处理，导致锁竞争、串行执行、事务延长、tempdb压力及死锁风险激增。
SQL Server触发器里用游标，基本等于给 INSERT/UPDATE/DELETE 加锁减速带——并发一上来，性能掉得比日志还快。
游标在触发器中为什么直接拖垮并发性能
SQL Server 的执行引擎天生为集合操作优化，而游标强制把 INSERT INTO orders SELECT ... 这类批量操作，拆成 N 次单行 FETCH + 处理。每一轮 FETCH 都要：重新定位行、加行锁（或页锁）、维持游标状态、触发上下文切换。这些开销在单行插入时几乎不可见，但 100 行插入时，实际执行时间可能翻 5–10 倍。
- 游标无法并行：哪怕服务器有 32 核，
CURSOR FOR SELECT ... FROM inserted仍只能串行跑 - 锁持有时间拉长：游标遍历时若做
UPDATE或调用存储过程，事务持续时间变长，阻塞其他会话对同一张表的写入 - 内存与 tempdb 压力：动态游标会缓存结果集快照；静态游标则把整个
inserted表复制进tempdb，多并发下极易触发tempdb瓶颈 - 死锁风险上升：两个触发器分别用游标更新 A 表和 B 表，顺序稍有不一致，
@@FETCH_STATUS循环就可能成为死锁温床
什么时候游标在触发器里“看似合理”但其实危险
常见误判场景包括：“必须逐条发消息”“要调用含事务的存储过程”“需要按顺序生成流水号”。这些需求表面看需要游标，实则埋着并发雷：
-
INSERT INTO log_table SELECT ... FROM inserted能 1 次完成，偏用游标INSERTN 次 → 日志表写放大，索引维护开销倍增 - 调用
EXEC sp_do_something @id时传入单个@id→ 若该存储过程内部再查表、更新、发 HTTP，游标会把它串行化执行 N 次，彻底扼杀吞吐 - 依赖
@@CURSOR_ROWS或游标位置做条件分支 → 并发下结果不可预测，尤其遇到SET CURSOR_CLOSE_ON_COMMIT ON时更易出错
替代游标的三种可行路径（按推荐度排序）
真正需要“逐行语义”的场景极少，绝大多数可转为集合操作或解耦处理：
-
优先用集合 DML：比如审计日志，直接
INSERT INTO audit_log (...) SELECT i.id, i.name, SYSTEM_USER, GETDATE() FROM inserted i—— 一行 SQL 完成，无锁竞争，支持并行计划 -
用队列表 + 外部轮询服务：如需调外部 API，先
INSERT INTO outbox_queue (record_id, action) SELECT id, 'notify' FROM inserted，再由独立服务消费 —— 触发器秒级返回，压力转移，失败可重试 -
仅当绝对必要时才用游标，并加硬约束：限定最大行数（如
IF (SELECT COUNT(*) FROM inserted) > 100 BEGIN RAISERROR('Too many rows', 16, 1); RETURN; END），且必须显式CLOSE/DEALLOCATE，避免句柄泄漏
最常被忽略的一点：触发器里的游标没有“超时控制”机制。一旦某次 FETCH 卡住（比如下游服务响应慢），整个 INSERT 事务就挂起，连锁阻塞后续所有对该表的写操作——这不是延迟，是雪崩起点。
