inserted 是内存中的集合表，应直接 join 或子查询处理多行数据；禁用游标遍历，避免性能陷阱；复杂逻辑应解耦至外部服务；注意其事务生命周期与索引优化。
直接用 INSERT/UPDATE + FROM inserted 做集合操作
触发器里 inserted 是一张真实存在的内存表，不是游标、也不是单行变量。想“捕获多行”，根本不需要逐行读取——直接把它当普通表 JOIN 或子查询就行。常见错误是写 SELECT @id = id FROM inserted，这只会拿到某一行的值，其余全丢。
正确做法是把业务逻辑改写成面向集合的语句。比如要同步更新日志表：
INSERT INTO audit_log (table_name, row_id, op_type, created_at) SELECT 'orders', i.order_id, 'INSERT', GETDATE() FROM inserted i;
需要关联原表做校验或补字段？加 JOIN：
UPDATE t SET last_modified = GETDATE(), status_flag = 1
FROM orders t
INNER JOIN inserted i ON t.order_id = i.order_id
WHERE i.status IN ('shipped', 'cancelled');
- 所有操作都是一次性完成，不循环、不游标、不临时表
- WHERE 条件、JOIN、GROUP BY、窗口函数全可用
- 性能和可维护性远高于任何逐行方案
别用游标遍历 inserted 表
游标语法上能跑通，但它是触发器里最典型的性能陷阱。SQL Server 的 inserted 表本身已是集合，再套一层游标等于主动放弃数据库的并行和批量能力。
典型问题包括：
- 10 万行插入 → 触发器内执行 10 万次 FETCH + 10 万次 INSERT，I/O 和锁开销爆炸
- 游标默认不可并行，阻塞其他会话，高并发下极易死锁
-
@@FETCH_STATUS在并发场景下不稳定，漏处理或重复处理风险高 - 无法在函数中使用，复用性差，调试困难
除非你有强约束必须“每行调一次外部存储过程”（且已评估过性能代价），否则不要碰游标。
需要逐行回调时，用 change_log + 外部服务解耦
真有“每行触发不同业务逻辑”的需求（比如 status=1 发短信、status=2 写 Kafka、status=3 调支付接口），触发器本身不是合适载体。SQL Server 触发器不支持动态 SQL、不能跨库调用 HTTP、也不允许在 AFTER 触发器里对本表再做 DML。
可行路径是两阶段：
- 触发器只干一件事：
INSERT INTO change_log SELECT id, old_status, new_status, 'UPDATE', GETDATE() FROM inserted i JOIN deleted d ON i.id = d.id - 独立服务（Python/Go 脚本）定时拉取
change_log中未处理的记录，按id查原始数据，再分发到对应下游
这样既保留了数据库层的变更捕获能力，又把复杂分支、重试、监控、超时等逻辑移出事务关键路径。
注意 inserted 表的生命周期和事务边界
inserted 表只在触发器执行期间存在，且内容完全由当前语句决定：单行 INSERT → inserted 一行；批量 INSERT … VALUES (…), (…) → inserted 多行；BULK INSERT → inserted 仍为完整批次数据。
但要注意：
- AFTER 触发器中修改原表，不会再次触发自身（无递归），但可能触发其他触发器
- 如果触发器里用了事务控制（如 BEGIN TRAN），
inserted数据仍可见，但回滚后整个变更（含触发器写入）都会撤销 - 不要在触发器里查
inserted以外的本表数据做判断——可能读到未提交的脏数据，尤其没加WITH (NOLOCK)时
最易被忽略的是：触发器逻辑越重，批量操作退化得越彻底。哪怕物理上是 1000 行一起进来的，只要触发器里有一条没走索引的子查询，实际就变成 1000 次随机 I/O。
