在SQL Server中，INSERT OUTPUT的位置必须紧挨着INSERT INTO之后，且在VALUES之前，它不支持RETURNING关键字。在使用时，需要用OUTPUT INSERTED.id等方式来指定字段，其中INSERTED前缀不可省略，并且最终的结果必须通过ExecuteScalar或者表变量来承接。

SQL Server INSERT OUTPUT必须跟在VALUES前面

不少人会写成 INSERT INTO users (...) VALUES (...) RETURNING id，结果直接报错 Incorrect syntax near 'RETURNING'。要知道，SQL Server 根本不支持 RETURNING 这个玩意儿，它只认 OUTPUT，而且这 OUTPUT 的位置可是相当关键哦！它必须紧紧地接在 INSERT INTO ... 后面，然后在 VALUES（或者 SELECT）之前。

正确写法是：

INSERT INTO users (name, email) 
OUTPUT INSERTED.id, INSERTED.created_at 
VALUES ('Charlie', 'c@example.com');

• INSERTED 是保留关键字，不能省略或拼错；写成 inserted（小写）虽不报错但属于习惯问题，建议统一大写保持可读性
• 如果表有计算列或默认值（比如 created_at DEFAULT GETDATE()），OUTPUT INSERTED.created_at 拿到的就是插入时实际生成的值，不是 NULL
• 不能单独执行 OUTPUT 子句——它必须依附于 INSERT/UPDATE/DELETE，否则语法错误

OUTPUT INSERTED.* 和 OUTPUT INSERTED.id 性能差异明显

用 OUTPUT INSERTED.* 看起来省事，但实际会把整行所有字段都序列化返回，包括大文本（TEXT、NVARCHAR(MAX)）、二进制（VARBINARY）等字段，哪怕你只需要一个 id。

尤其在高并发插入场景下，网络传输和客户端内存开销会显著上升。更隐蔽的问题是：如果某列是 SPARSE 或含 FILESTREAM，INSERTED.* 可能触发额外 I/O。

• 只选必要字段，比如 OUTPUT INSERTED.id, INSERTED.version
• 避免在批量插入（INSERT ... SELECT）中用 INSERTED.*，返回结果集体积不可控
• 若需调试，临时用 INSERTED.* 没问题；上线前务必收敛字段列表

OUTPUT 结果不能直接当变量用，得靠 ExecuteScalar 或临时表承接

执行带 OUTPUT 的语句后，结果不是自动赋给某个变量的。常见误解是以为 DECLARE @new_id INT; INSERT ... OUTPUT INSERTED.id 就能把值塞进 @new_id——不行，SQL Server 不支持这种隐式赋值。

正确承接方式分两种：

• 应用层调用时，用 ExecuteScalar()（如 ADO.NET）直接取第一行第一列：int id = (int)cmd.ExecuteScalar();
• 想在同一批 T-SQL 里继续用，得用临时表或表变量接收：OUTPUT INSERTED.id INTO @temp_ids，然后 SELECT @new_id = id FROM @temp_ids
• 注意：如果插入零行，ExecuteScalar() 返回 null，不是 0；表变量里也查不到数据，别漏判空

事务中 OUTPUT 返回的是未提交数据，其他会话看不见

这点和 PostgreSQL 的 RETURNING 行为一致，但容易被忽略。在事务内执行 INSERT ... OUTPUT，拿到的 INSERTED 值确实是刚写入的，但它对其他连接不可见，直到 COMMIT。

这意味着：

• 不能靠它做跨连接的“实时通知”——比如插入后立刻让另一个服务查这个 ID，查不到
• 如果事务回滚，OUTPUT 返回的值就作废了，但应用层已经拿到了，后续逻辑要自己处理一致性
• 在存储过程中使用时，别假设 OUTPUT 返回的 ID 已“落地”，它只是当前事务快照里的值

真正需要强一致性反馈的场景，比如发消息、更新缓存，得等事务提交后再触发，不能只依赖 OUTPUT 的即时返回。

《夸克》非常好用的免费AI浏览器

下载APP查看