t-sql触发器中不应使用游标遍历inserted表，因其是集合而非单行；应采用join、update...from等集合操作批量处理，并用exists校验全局约束，复杂逻辑须拆至队列表+后台作业。
触发器里不能用游标遍历 Inserted 表
直接上结论：T-SQL 触发器中 不应当、也不需要 用游标或循环去逐行处理 Inserted 表。这是最常见的设计误判——把触发器当成了“每插入一行就触发一次”的过程式逻辑，而实际上 INSERT 语句无论影响 1 行还是 10000 行，都只触发一次，Inserted 是一个**结果集表**，不是单行变量。
常见错误现象：Cursor fetch returned no data 或触发器只处理了第一条、其余静默失败；更隐蔽的是在高并发下因游标锁表导致阻塞或死锁。
- 触发器本质是集合操作，应使用集合语句（
JOIN、EXISTS、UPDATE ... FROM）一次性处理整个Inserted - 若业务逻辑真需“逐行效果”（如调用外部存储过程、写日志带序号），必须改用集合等价写法，或把逻辑下推到应用层
-
@@ROWCOUNT在触发器开头可能为 0（受 SET 选项或前序语句干扰），不可靠；应查SELECT COUNT(*) FROM Inserted确认数据量
用 UPDATE ... FROM 或 JOIN 批量更新关联表
这是最典型场景：主表插入后，需同步更新订单状态、库存、统计汇总等。关键在于把 Inserted 当作普通表参与连接，而非逐行读取。
示例：订单表 Orders 插入后，自动在 OrderSummary 中累加金额：
UPDATE os
SET TotalAmount = os.TotalAmount + i.Amount,
OrderCount = os.OrderCount + 1
FROM OrderSummary os
INNER JOIN Inserted i ON os.YearMonth = FORMAT(i.OrderDate, 'yyyyMM');
注意点：
- 务必用
INNER JOIN或LEFT JOIN明确关联条件，避免笛卡尔积——Inserted有 1000 行，OrderSummary有 100 行，没ON就是 10 万次更新 - 不要在
WHERE中写id IN (SELECT id FROM Inserted)，这会强制嵌套循环，性能陡降；优先走JOIN - 如果关联目标表无对应记录（如首次汇总），需配合
MERGE或先INSERT再UPDATE
用 EXISTS 或 NOT EXISTS 做存在性校验
很多业务要求“禁止插入重复组合”，比如同一用户当天只能提交一个申请。这类检查必须基于整个 Inserted 集合做全局判断，而不是逐行查。
错误写法：IF EXISTS (SELECT 1 FROM Users u WHERE u.UserID = (SELECT TOP 1 UserID FROM Inserted)) ... —— 只校验了第一行，且 TOP 1 无序，结果不可靠。
正确写法：
IF EXISTS (
SELECT 1
FROM Inserted i
INNER JOIN Applications a
ON a.UserID = i.UserID AND a.AppDate = CAST(i.CreatedTime AS DATE)
)
BEGIN
RAISERROR('同一用户当日已提交申请', 16, 1);
ROLLBACK;
RETURN;
END
要点：
- 子查询里直接
JOIN Inserted，确保覆盖所有新插入行 - 避免在
WHERE中对Inserted列用函数（如YEAR(i.CreatedTime) = YEAR(GETDATE())），会导致索引失效；用范围比较更好：i.CreatedTime >= CAST(GETDATE() AS DATE) - 校验失败必须显式
ROLLBACK，否则事务继续执行，可能留下脏数据
复杂逻辑必须拆出存储过程，但别在触发器里调用
如果业务规则涉及多表计算、条件分支极多、或要写审计日志带时间戳/操作人，硬塞进触发器会严重拖慢主 DML 性能，且难以测试和维护。
可行路径：
- 触发器只做轻量级动作（如设置
CreatedTime、CreatedBy、简单状态标记），然后把Inserted的关键字段（如ID,EventType）写入一张轻量队列表（TriggerQueue） - 由后台作业（SQL Agent Job 或应用服务）轮询该队列表，批量消费并执行完整逻辑
- 绝对避免在触发器中调用含事务、远程调用、长时间等待的存储过程——它会把整个 INSERT 事务卡住
容易被忽略的一点：Inserted 表在触发器结束后即销毁，任何想“缓存它供后续步骤用”的尝试都是徒劳的；所有依赖必须在当前触发器作用域内完成，或通过持久化中间表传递。
