SQL Server中SCOPE_IDENTITY()与GO的行为困惑及咨询

嘿，这个问题其实戳中了很多人对SQL Server批处理和SCOPE_IDENTITY()作用域的常见误解，我来给你拆解清楚：

首先，纠正一个关键认知：GO是客户端工具命令，不是T-SQL语法 #

GO并不是SQL Server本身识别的T-SQL语句，它是SSMS、sqlcmd这类客户端工具的批处理分隔符。它的作用是告诉客户端：把GO之间的代码块作为独立的批处理，单独发送给SQL Server执行。

然后，明确SCOPE_IDENTITY()的作用域规则 #

根据官方定义，SCOPE_IDENTITY()返回的是同一作用域（模块：存储过程、触发器、函数或批处理）中最后插入的标识值。这里的“批处理”指的是客户端发送给SQL Server的单个代码块——也就是被GO分隔出来的每一段代码。

那为什么你看到的示例结果里，被GO分隔的SELECT SCOPE_IDENTITY()返回了21？这里大概率是两个原因之一：

1. 官方文档示例的排版可能有误导 #

仔细看官方文档的示例，可能存在排版误差——实际正确的示例应该是INSERT和SELECT SCOPE_IDENTITY()处于同一个批处理中（没有被GO分隔），这样两者属于同一作用域，返回21就完全合理。比如正确的脚本应该是：

USE AdventureWorks2012; 
GO 
-- 同一个批处理：INSERT + SELECT
INSERT INTO Person.ContactType ([Name]) VALUES ('Assistant to the Manager'); 
SELECT SCOPE_IDENTITY() AS [SCOPE_IDENTITY]; 
GO 
SELECT @@IDENTITY AS [@@IDENTITY]; 
GO

这种情况下，SCOPE_IDENTITY()和@@IDENTITY都会返回21，因为INSERT和第一个SELECT在同一个作用域，而@@IDENTITY是会话级的，不管批处理。

2. 你执行脚本时的操作导致批处理未正确分隔 #

如果你在SSMS中执行脚本时，不小心选中了INSERT和SELECT SCOPE_IDENTITY()两段代码一起执行（跳过了GO的分隔作用），那它们会被作为同一个批处理发送给SQL Server，自然SCOPE_IDENTITY()会返回插入的标识值。

验证正确行为的测试 #

你可以自己做个简单测试来验证：

1. 创建一个测试表：

CREATE TABLE TestIdentity (ID INT IDENTITY(1,1), Name VARCHAR(50));
GO

2. 执行插入和跨批查询：

INSERT INTO TestIdentity (Name) VALUES ('Test Batch 1');
GO
-- 这是单独的批处理，没有插入操作
SELECT SCOPE_IDENTITY() AS ScopeID, @@IDENTITY AS SessionID;
GO

执行结果应该是：

ScopeID | SessionID
NULL    | 1

这里SCOPE_IDENTITY()返回NULL（当前批处理没有插入），而@@IDENTITY返回1（当前会话的最后插入值），这才是符合规则的结果。

总结一下：SCOPE_IDENTITY()的作用域严格限定在单个批处理/模块内，跨批处理的话一定会返回NULL。你看到的异常结果要么是示例排版问题，要么是执行时的批处理分隔错误。

内容的提问来源于stack exchange，提问作者j_maly