SQL Server触发器中inserted是表而非单行变量，必须用集合操作（如GROUP BY+SUM）处理多行，禁用@var=(SELECT...)、游标或逐行逻辑，测试需用多行含重复键值的数据验证。
SQL Server触发器中inserted是表，不是单行变量
很多开发者在编写触发器时，会下意识地沿用处理单行数据的习惯，比如使用@var = (SELECT xxx FROM inserted)这样的赋值语句。结果呢？一旦遇到批量插入操作，触发器往往只对第一行数据生效，后面的数据就“消失”了。这背后的原因其实很直接：这类子查询在返回多行时会直接报错；而如果为了规避错误加上TOP 1或者没有明确的ORDER BY，就等于随机选取了一行，逻辑自然就错了。
问题的根源在于对inserted和deleted这两个逻辑表的认知。它们可不是什么简单的变量，而是**结构与被操作表完全一致的临时表**。这张表里可能包含零行、一行，也可能是成百上千行。因此，处理触发器的第一要务，就是彻底抛弃“逐行处理”的思维定式，转向基于集合的操作方式。举个例子，当需要更新父表的某个汇总字段时，正确的思路不是逐行累加LineTotal，而是应该先对inserted表按业务键进行分组和聚合计算。
用SUM()和GROUP BY处理多行插入的汇总逻辑
来看一个典型场景：向订单明细表PurchaseOrderDetail中插入多行记录时，需要将新增的明细金额累加到对应的订单头表PurchaseOrderHeader.SubTotal字段中。一个常见的错误写法是直接在触发器里引用inserted.LineTotal进行累加，这必然导致只有一行数据被计入。
正确的做法，是分两步走：
- 第一步，聚合计算。 先对
inserted临时表按PurchaseOrderID进行分组，并计算出每个订单新增的明细总额：SELECT PurchaseOrderID, SUM(LineTotal) AS TotalLine FROM inserted GROUP BY PurchaseOrderID。 - 第二步，关联更新。 使用
UPDATE ... FROM语法，将聚合结果与父表关联起来进行更新：UPDATE h SET SubTotal = h.SubTotal + g.TotalLine FROM PurchaseOrderHeader h INNER JOIN (SELECT PurchaseOrderID, SUM(LineTotal) AS TotalLine FROM inserted GROUP BY PurchaseOrderID) g ON h.PurchaseOrderID = g.PurchaseOrderID。
这里有个细节值得注意：更新条件必须通过JOIN关联来限定，而不是写成WHERE h.PurchaseOrderID IN (SELECT PurchaseOrderID FROM inserted)。为什么？因为如果inserted表中同一个PurchaseOrderID出现了多次（多行明细属于同一订单），IN子句可能会导致更新逻辑错乱或遗漏，而分组聚合后的JOIN则能确保每个订单只被正确地更新一次。
避免用游标或变量遍历inserted表
或许是为了追求“可控”，有些方案会选择声明游标来遍历inserted表，或者使用WHILE @@ROWCOUNT > 0循环配合TOP 1来逐行处理。这两种方法，不仅效率低下，更是潜在的错误之源。SQL Server的触发器机制本身就是为集合操作而设计的，使用游标会显著增加锁竞争，严重拖慢批量操作的性能，而且遍历的顺序也无法得到保证。
- 并发问题： 在高并发插入场景下，游标读取的
inserted快照可能并不一致。 - 未定义行为： 像
SELECT @id = PurchaseOrderID FROM inserted这样的变量赋值语句，当inserted包含多行时，其赋值结果是未定义的（SQL Server通常返回最后一行，但这并非绝对保证）。 - 正确的异步处理： 如果业务上确实存在需要逐行处理的逻辑（例如为每一行记录发送消息或调用外部API），更合理的架构是将
inserted表中的数据先插入到一个专门的队列表中，然后由后台作业异步处理，而不是在触发器中同步执行，阻塞整个事务。
测试触发器是否真正支持多行的简单方法
测试环节是验证逻辑的最后一道关卡，但方法不对，努力白费。千万不要只用INSERT INTO ... VALUES (...)插入单行数据来测试触发器。那样测不出任何问题。
必须采用能模拟真实批处理场景的测试方法：使用INSERT INTO ... SELECT或者INSERT INTO ... VALUES (...), (...), (...)语法，一次性插入至少两行数据。并且，测试数据中至少要包含一个重复的外键值（例如，两条明细记录指向同一个PurchaseOrderID）。插入完成后，再去检查目标表（如订单头表）中的汇总字段，其值是否精确等于所有相关明细行LineTotal的总和。
还有一个容易踩坑的地方：如果在触发器逻辑中混合使用了@@ROWCOUNT来判断影响行数，或者依赖SCOPE_IDENTITY()这类标量函数，需要格外小心。它们感知的是上一条语句的影响，而非inserted表的实际行数，这种不一致性会让调试过程变得更加隐蔽和困难。
