触发器中output into物理表受限于sql server引擎级限制，仅允许写入表变量、本地/全局临时表；审计需“两步走”；update触发器中deleted/inserted须严格匹配操作类型；output应优先用于主dml语句而非触发器；其结果集不受事务回滚影响。
触发器里不能直接用 OUTPUT INTO 物理表
OUTPUT 子句在触发器中不是不能用，而是不能往带约束的物理表里写 —— SQL Server 明确禁止 OUTPUT INTO 目标表参与 FOREIGN KEY、有 CHECK 约束、或启用了触发器本身。而审计表恰恰常设这些约束，结果一执行就报错：The target table 'AuditLog' of the DML statement cannot have any enabled triggers.
这不是配置问题，是引擎级限制。哪怕你把触发器设成 INSTEAD OF，只要目标表上存在任何启用的触发器（包括它自己），OUTPUT INTO 就会失败。
- 唯一能安全
INTO的目标只有：已声明的@table_variable、本地临时表#temp、或全局临时表##temp - 但临时表生命周期短，跨批丢失；表变量无法被后续语句（如 INSERT INTO AuditLog）直接引用，除非再 SELECT 出来
- 想存到物理审计表？得靠“两步走”：先
OUTPUT INTO @AuditRows，再INSERT INTO AuditLog SELECT * FROM @AuditRows
UPDATE 触发器中误用 DELETED/INSERTED 是高频错误
在 AFTER UPDATE 触发器里，DELETED 和 INSERTED 是现成的虚拟表，但很多人直接在 OUTPUT 里混用，比如写 OUTPUT DELETED.ID, INSERTED.Name INTO @log —— 这没问题；但若触发器主体是 INSERT，却写了 DELETED.ID，SQL Server 会立刻报错：The column prefix 'DELETED' does not match with a table name or alias name used in the query.
关键不是语法错，是逻辑错：触发器类型决定了可用虚拟表。必须严格匹配：
-
INSERT触发器 → 只能用INSERTED.* -
DELETE触发器 → 只能用DELETED.* -
UPDATE触发器 →DELETED和INSERTED都可用，但列名必须明确区分（如DELETED.Email AS OldEmail,INSERTED.Email AS NewEmail） - 别指望
OUTPUT自动推导操作类型 —— 它不提供$action（那是MERGE专用），得手动加常量：'UPDATE'或'INSERT'
用 OUTPUT 替代触发器日志是更轻量的选择
真正需要审计时，优先考虑把 OUTPUT 直接写进主 DML 语句，而不是套一层触发器。例如，业务代码执行 UPDATE Orders SET Status = 'Shipped' WHERE OrderID = 123，就在同一语句后加 OUTPUT INSERTED.OrderID, INSERTED.Status, GETDATE(), 'UPDATE' INTO OrderAudit。
这样做的好处很实在：
- 少一次触发器调用开销，尤其高并发下延迟更可控
- 事务上下文一致：主 DML 和审计写入原子性绑定，不会出现主表成功但日志失败的情况
- 避免嵌套问题：触发器里再发 INSERT + OUTPUT，容易触发递归或锁等待
- 调试友好：日志逻辑和业务逻辑在同一处，改起来不跳转
当然，前提是业务层能控制 SQL 拼装 —— ORM 或存储过程封装好的场景，就得权衡是否值得改造。
OUTPUT 结果在事务回滚后仍有效是个陷阱
这是最容易被忽略的细节：OUTPUT 返回的结果集（无论是否 INTO）**不受事务回滚影响**。也就是说，如果主 DML 语句因后续错误回滚了，OUTPUT 已经输出的行、或已插入 @table_variable 的数据依然存在。
这意味着：
- 若用
OUTPUT INTO @log后做条件判断（比如“修改了超过100行就发告警”），这个判断依据的是实际执行时的快照，不是最终持久化状态 - 若把
@log内容再 INSERT 到物理审计表，而主事务回滚，就会造成“审计记录存在但主表没变”的不一致 - 安全做法是：只把
OUTPUT当作中间态，所有落盘动作（INSERT INTO AuditTable）必须和主 DML 在同一事务块内，且放在主语句之后、COMMIT 之前
