SCOPE_IDENTITY() 是 SQL Server 中最稳妥的获取刚插入记录自增 ID 的方式，因其严格限定在同一作用域内返回本作用域最后插入的标识值，避免触发器干扰和跨会话污染。
SCOPE_IDENTITY() 是 SQL Server 中最稳妥的获取刚插入记录自增 ID 的方式，只要你的 INSERT 和获取操作在同一个作用域（比如同一批处理、同一个存储过程）里，它就几乎不会出错。用错 @@IDENTITY 或 IDENT_CURRENT() 是生产环境 ID 错乱的常见源头。
为什么不能直接用 SELECT @@IDENTITY
因为 @@IDENTITY 不认“作用域”，只认“当前会话中最后生成的标识值”。一旦表上有 INSERT 触发器，且触发器又往另一张带 IDENTITY 列的表里插了数据，@@IDENTITY 就会返回触发器插入的 ID，而不是你本意要的那条。
常见错误现象：
- 你在
Orders表插入订单，期望拿到OrderID - 但
Orders上有个触发器，自动往AuditLog表写日志（AuditLog.ID也是IDENTITY） - 结果
SELECT @@IDENTITY返回的是AuditLog.ID，不是OrderID
这种错位在并发场景下更隐蔽，查半天才发现是触发器偷偷“抢”了标识值。
SCOPE_IDENTITY() 必须和 INSERT 在同一作用域
作用域不是“同一事务”，也不是“同一连接”，而是指：同一批处理（如 SSMS 中一次执行的多条语句）、同一个存储过程、同一个函数或同一个触发器内部。跨作用域调用会失效。
实操要点：
- INSERT 和
SELECT SCOPE_IDENTITY()必须写在同一个BEGIN...END块或同一批语句中，不能中间被 GO 分割 - 如果封装在存储过程中，确保调用方不把 INSERT 和 SELECT 拆开执行
- 在 C# 中用
SqlCommand.ExecuteScalar()执行单条含 INSERT +SELECT SCOPE_IDENTITY()的语句最安全，例如：INSERT INTO Users (Name) VALUES ('Alice'); SELECT SCOPE_IDENTITY(); - 别用
ExecuteNonQuery()再单独查SCOPE_IDENTITY()—— 那已经是另一个作用域了
返回值类型和 NULL 的含义要小心
SCOPE_IDENTITY() 返回 numeric(38,0)，不是 int。虽然大多数时候能隐式转换，但在强类型上下文（如某些 ORM 映射、参数化查询）中可能报错或截断。
它返回 NULL 只有两种情况：
- 当前作用域内根本没执行过任何向
IDENTITY列插入的操作 - 执行了 INSERT，但目标列不是
IDENTITY（比如显式插入了值，或表没定义IDENTITY）
注意：即使 INSERT 因主键冲突、约束失败而回滚，只要标识值已被分配（SQL Server 不回滚已递增的 identity 值），SCOPE_IDENTITY() 仍会返回那个已生成但未落库的 ID —— 这不是 bug，是 SQL Server 的设计行为。
和 IDENT_CURRENT() 的关键区别在哪
IDENT_CURRENT('TableName') 看起来更“精准”，因为它指定了表名，但它完全不关心会话和作用域 —— 任何人在任何连接里都能读到这张表最近生成的 ID。这在高并发写入时极不可靠。
典型风险场景：
- 你刚在自己的会话里插入一条，还没来得及取 ID
- 另一个会话紧接着也插入了一条
- 你再执行
SELECT IDENT_CURRENT('Users')，拿到的是别人刚插的 ID
所以除非你明确需要“跨会话监控某张表最新 ID”（比如做数据同步校验），否则不要用 IDENT_CURRENT() 替代 SCOPE_IDENTITY()。
实际写法最简也最稳的就这一行：
INSERT INTO Products (Name, Price) VALUES ('Widget', 29.99); SELECT SCOPE_IDENTITY();真正容易出问题的，从来不是语法，而是对“作用域”边界的误判——比如以为事务 = 作用域，或者把 INSERT 和 SELECT 拆成两次网络往返。
