OUTPUT子句在DELETE中需写为OUTPUT DELETED.column_name，仅支持DELETED虚拟表；可用OUTPUT...INTO存档删除数据，但目标表须预先存在且列兼容；其操作原子、可靠，性能优于SELECT+DELETE分步执行。
OUTPUT子句在DELETE语句中怎么写才有效
直接在 DELETE 后加 OUTPUT 就行，但必须指定要返回的列，不能只写 OUTPUT *（SQL Server 2005+ 支持，但不推荐）。DELETED 是唯一可用的虚拟表，代表被删前的行。
常见错误：写成 OUTPUT INSERTED.* 或漏掉 DELETED 前缀——这会报错 The multi-part identifier "INSERTED.id" could not be bound.
-
OUTPUT DELETED.id, DELETED.name✅ 明确、安全 -
OUTPUT DELETED.*⚠️ 可用，但列顺序/数量可能随表结构变化，不利于下游消费 -
OUTPUT INSERTED.id❌INSERTED在DELETE中不可用 - 没写
OUTPUT却期望返回结果集 —— 不会返回任何数据，语句静默执行
想把删掉的数据存到另一张表里，怎么用OUTPUT + INTO
OUTPUT ... INTO 是最实用的模式，能避免额外查询或临时表。目标表必须已存在，且列数、类型、顺序需严格匹配 OUTPUT 子句列出的字段。
典型场景：归档删除记录、审计日志、软删前快照。
- 目标表字段名不必和源表一致，但类型要兼容（如
DELETED.created_at是DATETIME，目标列也得是时间类型） - 不能用
SELECT INTO动态建表；INTO后只能跟已有表名 - 如果目标表有
IDENTITY列，需提前用SET IDENTITY_INSERT target_table ON - 示例：
DELETE FROM orders OUTPUT DELETED.order_id, DELETED.total INTO deleted_orders_archive (order_id, amount) WHERE status = 'cancelled';
OUTPUT在事务中是否可靠？会不会丢数据
可靠。OUTPUT 是原子操作的一部分，和 DELETE 共享同一事务上下文。只要事务提交，OUTPUT 返回的数据就和实际删除的行完全一致；事务回滚，则 OUTPUT 结果集为空，也不会写入 INTO 表。
容易被忽略的点：
- 如果
DELETE触发了触发器，OUTPUT**不捕获**触发器内部的修改，只反映原始DELETE操作影响的行 - 并发环境下，
OUTPUT返回的是该语句“看到”的快照，不受其他未提交事务干扰（基于当前隔离级别） - 无法在
OUTPUT中调用函数（如GETDATE()），也不能做计算字段（如DELETED.price * 1.1）——SQL Server 2016+ 允许简单表达式，但旧版本会报错
和SELECT + DELETE分两步比，OUTPUT有什么代价
性能更好，且规避了竞态风险。分两步做（先 SELECT 再 DELETE）需要加锁防止中间被改，而 OUTPUT 一步完成，锁持有时间更短。
但要注意：
-
OUTPUT会增加少量内存开销（用于暂存结果集），大批量删除（百万行以上）时，建议分批处理，否则可能引发tempdb压力或阻塞 - 不能在
OUTPUT中引用其他表的字段（比如JOIN后的字段），它只认DELETED和（在UPDATE中）INSERTED - 某些ORM（如 Entity Framework）不原生支持解析
OUTPUT结果，需用原始 SQL 或存储过程封装
真正麻烦的不是语法，而是忘记 DELETED 只能读、不能改，以及误以为 OUTPUT INTO 能自动建表——这两处卡住的人最多。
