应优先使用集合操作而非变量赋值或游标处理inserted表：多行插入时@var=col仅保留一行值，游标性能差且易出错；正确做法是用insert/update配合from inserted直接批量处理，必要时通过队列表+外部服务解耦逐行副作用。
触发器里用 @var = column 赋值会出错，因为多行插入时只取最后一行
SQL Server（及其他主流数据库）的触发器中，如果写 SELECT @id = id FROM inserted，当 INSERT 多行时，@id 最终只保留某一行的值（通常是最后处理的一行），其余行被覆盖。这不是“随机”，而是 SQL 标准行为：标量变量只能存一个值，而 inserted 是表，不是单行结果集。
常见错误现象：
— 单行 INSERT 正常，多行就漏记录或日志错乱
— 触发器调用存储过程传入 @id，但只处理了其中一行
— 更新关联表时只更新了一条，其他行没反应
- 别用
SELECT @var = col FROM inserted做多行场景的变量赋值 - 除非你明确只需要任意一行（比如仅用于日志打点），否则这属于逻辑缺陷
- SQL Server 2016+ 可用
STRING_AGG拼接，但仍是汇总，不是逐行处理
用游标逐行处理 inserted 表可行，但不推荐
游标能保证对 inserted 中每一行执行一次逻辑，语法上没错，但代价高、易出错、难维护。尤其在高频插入场景下，游标会显著拖慢 INSERT 性能，还可能引发阻塞或死锁。
典型写法（SQL Server）：
DECLARE cur CURSOR FOR SELECT id, name FROM inserted;
OPEN cur;
FETCH NEXT FROM cur INTO @id, @name;
WHILE @@FETCH_STATUS = 0
BEGIN
-- 处理单行逻辑，如 INSERT 到日志表、调用 API 包装函数等
INSERT INTO audit_log (table_name, record_id) VALUES ('users', @id);
FETCH NEXT FROM cur INTO @id, @name;
END;
CLOSE cur;
DEALLOCATE cur;
- 游标必须显式
OPEN/CLOSE/DEALLOCATE，漏掉任一环节会导致句柄泄漏 -
@@FETCH_STATUS在并发下不稳定，建议加IF @@FETCH_STATUS 0 BREAK防止死循环 - 游标无法并行，且不能在函数中使用，限制了复用性
优先用集合操作替代逐行逻辑
绝大多数触发器需求其实不需要“逐行”——比如写日志、更新统计字段、校验约束、同步到另一张表，都可以用单条 INSERT/UPDATE 配合 inserted 表完成。这才是 SQL 的本意：面向集合，不是面向行。
例如批量写审计日志：
INSERT INTO audit_log (table_name, record_id, action, created_at) SELECT 'orders', i.order_id, 'INSERT', GETDATE() FROM inserted i;
再如更新父表计数器：
UPDATE p SET order_count = p.order_count + i.cnt
FROM customers p
INNER JOIN (
SELECT customer_id, COUNT(*) AS cnt
FROM inserted
GROUP BY customer_id
) i ON p.id = i.customer_id;
- 所有操作天然支持多行，无需额外控制流
- 执行计划可优化，性能通常比游标快 5–50 倍（取决于数据量）
- 避免事务内长时间持有锁，降低阻塞风险
- 若需调用标量函数（如
fn_validate_email(@email)），改用APPLY或子查询，别硬套游标
真需要逐行副作用（如发 HTTP 请求、写文件）？换地方做
SQL Server 触发器本身不适合执行外部 I/O。哪怕用游标，sp_OACreate 或 CLR 调用也极不稳定，容易导致事务超时、连接中断、权限失败。
更可靠的做法是：
- 把关键字段（如主键、操作类型）写入一张轻量队列表（
trigger_queue），由外部服务（如 .NET Worker、Python Celery）轮询消费 - 用 Service Broker 实现异步解耦，但配置复杂，适合已用 SB 的系统
- 改用应用层拦截 INSERT —— 在 ORM 或 API 层统一处理，比在数据库里硬扛更可控
真正卡在“必须用触发器 + 必须逐行调外部”的场景极少。先确认是不是架构设计阶段就把责任放错了位置。
游标不是禁用，集合不是万能；但只要 inserted 出现在触发器里，第一反应就该是“能不能用 FROM inserted 直接干完”。那些绕不开的逐行副作用，往往说明触发器不该承担这个角色。
