SQL Server中INSTEAD OF INSERT触发器必须用集合操作处理inserted表，因其为结果集而非单行变量；错误使用SELECT TOP 1赋值会静默丢弃多行，正确做法是INSERT...SELECT...FROM inserted批量写入。
SQL Server 中 INSTEAD OF INSERT 必须用集合操作处理 inserted 表
视图插入多行时，inserted 是一个结果集，不是单行变量。常见错误是写 SELECT TOP 1 @id = id FROM inserted——这只会处理第一行，其余行被静默丢弃。
真正安全的做法是把整个 inserted 当作源表参与集合运算：
- 用
INSERT INTO ... SELECT ... FROM inserted批量写入，避免循环或标量赋值 - 对基表
NOT NULL列，必须显式提供默认值（如ISNULL(total, 0)），否则触发器直接报错 - 涉及外键依赖时，先插父表（如
customers），再插子表（如orders），顺序反了会触发FOREIGN KEY violation - 若 ORM 依赖新主键（如
SCOPE_IDENTITY()），得在触发器末尾加SELECT SCOPE_IDENTITY()或用OUTPUT子句返回
UPDATE 触发器里 WHERE 条件必须能唯一定位基表记录
视图字段名可能来自不同基表的同名列（比如 id 同时来自 users.id 和 profiles.id），触发器里不写前缀就会解析失败。
更关键的是：如果视图定义没暴露足够唯一字段（比如漏掉 orders.id，只返回 customer_name 和 status），你就没法写出安全的 WHERE orders.id = ? ——结果要么改错行，要么批量误更新。
- 检查视图 SELECT 列是否包含所有基表主键或唯一约束字段
- UPDATE 逻辑中必须用
:OLD（Oracle/PostgreSQL）或deleted（SQL Server）来匹配原记录，不能只靠视图字段值推断 - LEFT JOIN 视图中，右表字段为 NULL 时，要额外判断是否需 INSERT 还是 UPDATE，不能无条件执行
哪些数据库真支持 INSTEAD OF 触发器作用于视图？
支持程度差异极大，不能跨库复用：
-
SQL Server：完全支持，可建在任意复杂视图上，INSERT/UPDATE/DELETE全覆盖 -
PostgreSQL：需配合函数 +INSTEAD OF触发器，语法更冗长但功能等效 -
Oracle：仅支持FOR EACH ROW行级触发器，且视图不能带WITH CHECK OPTION；嵌套对象类型会额外受限 -
MySQL：完全不支持INSTEAD OF，遇到多表视图只能靠应用层拆解逻辑
别指望把 SQL Server 的触发器脚本直接扔进 MySQL 或 Oracle 里跑通。
触发器体里不能省略事务控制和业务校验
INSTEAD OF 触发器接管的是 DML 控制权，不是“让数据库闭眼放行”。它本身就在事务内运行，但你得主动做该做的事：
- 插入客户前，得查信用额度是否超限；更新订单状态前，得验证当前状态是否允许流转——这些逻辑必须手写，数据库不会自动补
- 多表写入场景（如订单+订单项视图），任一语句失败都会导致整个事务回滚，但你要确保回滚前没留下脏数据（比如先插了客户、再插订单失败，客户记录就得删或标记为待清理）
- 触发器里不能依赖
@@ROWCOUNT或SCOPE_IDENTITY()的隐式行为，尤其跨语句时，要用SET NOCOUNT OFF和显式OUTPUT保证客户端收到正确反馈
最常被忽略的一点：视图字段和基表列之间的 NULL 映射关系，不是语法问题，是业务语义问题——触发器里少一行 ISNULL(..., 'N/A')，上线后就可能卡住整条插入流水线。
