MERGE 的 OUTPUT 子句比 UPDATE + SELECT 更可靠，因其提供语句级原子反馈，确保返回的变更行与实际执行完全一致；而后者易受并发、事务隔离和逻辑不一致影响。
为什么 MERGE 的 OUTPUT 子句比 UPDATE + SELECT 更可靠
直接在 MERGE 中用 OUTPUT 拿变更结果，能确保你看到的“哪些行被改了”和实际执行的修改完全一致。如果先 UPDATE 再 SELECT 差异，中间可能有并发写入、事务未提交、或条件判断逻辑不一致的问题，结果就不可信。
关键点在于：OUTPUT 是语句级原子反馈，它只反映本次 MERGE 真正触达的行，不依赖额外查询逻辑或时间窗口。
如何用 OUTPUT 返回插入/更新/删除的具体行数据
OUTPUT 支持引用 INSERTED 和 DELETED 伪表，但要注意：它们只在对应操作发生时有值；没发生的操作，对应列返回 NULL。常用组合包括：
-
OUTPUT $action, INSERTED.id, INSERTED.name, DELETED.name—— 返回动作类型和新旧值 -
OUTPUT INSERTED.*, DELETED.*—— 全字段对比（需目标表字段名无歧义） -
OUTPUT $action, INSERTED.id, ISNULL(INSERTED.updated_at, GETDATE())—— 可嵌套函数或常量
注意：$action 是字符串，值为 'INSERT'、'UPDATE' 或 'DELETE'，必须大写且带单引号。
关联子查询作为源表时 OUTPUT 的常见陷阱
当 USING 后跟的是带 JOIN 的子查询（比如从临时表 + 主表拼出业务数据），OUTPUT 仍只反映目标表的变更，**不会自动带出源表字段**。若要返回源字段，必须显式在子查询中 SELECT 出来并起别名，再在 OUTPUT 中引用：
MERGE target_table AS t USING ( SELECT s.id, s.name, s.status, src.upload_time FROM staging_data AS s INNER JOIN upload_log AS src ON s.batch_id = src.id ) AS s ON t.id = s.id WHEN MATCHED THEN UPDATE SET t.name = s.name, t.status = s.status WHEN NOT MATCHED THEN INSERT (id, name, status) VALUES (s.id, s.name, s.status) OUTPUT $action, INSERTED.id, s.upload_time, INSERTED.status;
这里 s.upload_time 能用，是因为它在 USING 子查询里已暴露；如果漏写，OUTPUT 会报错 “invalid column name”。
带 TOP 或过滤条件时 OUTPUT 的行为确认
TOP (n) 和 WHEN ... AND 条件都会影响 OUTPUT 的输出行数，但影响方式不同：
-
TOP (100)限制的是参与匹配的最多行数，OUTPUT只返回这 100 行中实际触发操作的那些 -
WHEN MATCHED AND t.updated_at < GETDATE() - 1这类附加条件，会让部分匹配行跳过UPDATE，也就不会出现在OUTPUT中 - 所有被
OUTPUT返回的行，其$action值严格对应最终执行的操作，不会出现“匹配了但没更新却显示 UPDATE”的情况
真正容易被忽略的是：如果目标表有触发器（尤其是 INSTEAD OF），OUTPUT 仍按 MERGE 语义返回，但实际数据可能已被触发器拦截或改写——这时 OUTPUT 和最终表状态可能不一致。务必禁用或绕过触发器再用 OUTPUT 做校验。
