触发器中对inserted表使用标量变量赋值会导致多行错误；应改用集合操作，如JOIN、CTE或ROW_NUMBER()，避免游标和循环。
触发器里用 SELECT @var = column FROM inserted 会出错
这是最典型的多行插入陷阱。当 INSERT INTO ... VALUES (...), (...) 或批量导入触发触发器时，inserted 是一个结果集，不是单行。用标量变量直接赋值，SQL Server 会任意取一行（甚至报错：「子查询返回了多个值」），逻辑完全不可控。
实操建议：
- 永远避免在触发器中对
inserted或deleted做单行假设； - 把
@var类变量替换为临时表或 CTE，用集合操作处理整批数据； - 如果真要“为每行生成唯一编号”，改用
ROW_NUMBER() OVER (ORDER BY ...)配合JOIN，而不是循环或变量累加。
用 JOIN inserted 替代游标或 while 循环
有人写触发器时发现“必须逐行处理”，就上 DECLARE @id INT; DECLARE cur CURSOR... —— 这不仅慢，还容易锁表、死锁，且无法保证并发安全。
实操建议：
- 把业务逻辑重构成可向量化操作：比如“插入订单时检查客户余额是否足够”，应写成
UPDATE c SET c.Balance = c.Balance - i.TotalAmount FROM Customers c INNER JOIN inserted i ON c.CustomerID = i.CustomerID； - 配合
WHERE EXISTS (SELECT 1 FROM inserted i WHERE i.CustomerID = c.CustomerID AND c.Balance 做前置校验； - 所有涉及更新/删除/日志记录的操作，一律用
INSERT INTO LogTable SELECT ... FROM inserted，而非拼接字符串再EXEC。
INSTEAD OF INSERT 比 AFTER INSERT 更适合拦截非法数据
很多人用 AFTER INSERT 触发器查出问题再 ROLLBACK，但此时数据已进表（哪怕回滚，IDENTITY 和触发器内其他副作用可能已发生），还可能被其他会话提前读到脏数据。
实操建议：
- 对强校验场景（如金额不能为负、状态迁移必须符合规则），优先用
INSTEAD OF INSERT； - 在里面用
INSERT INTO target_table SELECT ... FROM inserted WHERE ...筛出合法行，再用INSERT INTO error_log SELECT ... FROM inserted WHERE NOT (...)记录拒绝原因； - 注意：
INSTEAD OF不会自动触发级联约束或FOREIGN KEY检查，这些得自己在逻辑里补全。
触发器里调用存储过程容易掩盖 SET-BASED 问题
把校验逻辑封装进 sp_CheckOrder，然后在触发器里 EXEC sp_CheckOrder @OrderID —— 看似整洁，实则灾难：这个存储过程大概率是按单行写的，遇到多行插入就只校验第一行，其余静默通过。
实操建议：
- 触发器中调用的存储过程，参数必须支持表值参数（
TVP）或至少接受inserted的等效结构； - 更推荐直接把校验逻辑写在触发器内（用
JOIN+CASE+ 窗口函数），避免抽象层引入隐式单行假设； - 如果非要用外部过程，确保它返回的是与
inserted行数一致的结果集，并用LEFT JOIN关联原数据做一致性判断。
真正难的不是写对一行，而是让同一段逻辑在 1 行、1000 行、跨事务并发插入时行为完全一致——SET-BASED 思维的本质，是承认 inserted 永远是个集合，而不是一个可以被“取出来看看”的变量。
