sql server触发器批量更新“失效”主因是误将inserted/deleted当单行处理；正确做法是用join+聚合实现集合操作，避免标量变量、游标及子查询多行赋值。
SQL Server触发器在批量更新时“失效”，绝大多数情况不是触发器没被调用，而是逻辑只处理了inserted或deleted中的一行——因为用了标量变量赋值、游标，或误把表当单行结果集用。
为什么@id = (SELECT id FROM inserted)在多行时会出问题
这条语句在单行插入时看似正常，但批量执行时：SELECT id FROM inserted返回多行，而@id是标量变量，只能存一个值。SQL Server 不报错，但行为未定义（通常取最后一行，不保证）。
- 常见错误现象：日志只记了一条、汇总字段只加了一行、关联更新只命中一个主键
- 根本原因：
inserted和deleted是真实临时表，不是“当前行”容器 - 别指望
TOP 1+ORDER BY来“修复”——这仍是逐行思维，且掩盖了集合缺失的问题
用UPDATE ... FROM inserted直接批量更新的写法要点
正确做法是让UPDATE语句天然适配多行输入，靠JOIN和聚合驱动，而不是靠变量中转。
- 避免写：
UPDATE t SET total = total + (SELECT LineTotal FROM inserted)（子查询多行报错） - 应写：
UPDATE h SET SubTotal = h.SubTotal + g.TotalLine FROM Header h INNER JOIN (SELECT PurchaseOrderID, SUM(LineTotal) AS TotalLine FROM inserted GROUP BY PurchaseOrderID) g ON h.PurchaseOrderID = g.PurchaseOrderID -
WHERE条件必须落在JOIN之后，不能写成WHERE h.id IN (SELECT id FROM inserted)——否则可能漏掉重复PurchaseOrderID的聚合结果 - 确保
Header表上的关联字段（如PurchaseOrderID）有索引，否则JOIN性能会断崖下跌
测试触发器是否真支持多行的最低成本方法
只用INSERT INTO ... VALUES (...)单行测试，等于没测。必须模拟真实批量场景。
- 用
INSERT INTO T SELECT ... FROM S WHERE ...或INSERT INTO T VALUES (), (), ()一次插 ≥2 行 - 关键：至少包含一个重复业务键（如两个明细行共用同一个
PurchaseOrderID），否则看不出聚合逻辑是否生效 - 检查目标表更新结果是否与
SELECT SUM(...)手算一致，而非只看“有没有变” - 不要依赖
PRINT或RAISERROR输出行数——它们在批量触发时只显示一次，无法反映实际处理行数
真正难的不是写出能跑的触发器，而是放弃“这一行刚进来，我立刻处理它”的直觉。只要代码里还出现@var =、DECLARE CURSOR、或任何试图把inserted当单行用的地方，它就在批量场景下不可信。
