在SQLServer中，标识列（IDENTITY）由数据库引擎自动维护自增值，常用于主键。但在数据迁移、历史补录或测试造数时，我们往往需要手动写入指定的标识值。如果直接写INSERT而不做处理，就会触发报错。下面先通过一张示意图了解基础环境。
一、标识列的默认行为与报错原理
当我们创建一张带标识列的表时，SQLServer会在系统目录里记录当前种子（seed）和增量（increment）。每次执行INSERT且不指定该列时，引擎自动计算下一个值并写入。如果INSERT语句中显式出现了标识列，且会话没有打开特定开关，就会拒绝操作。
例如下面这张用户表，Id为标识列，从1开始每次加1：
CREATE TABLE dbo.Users
(
Id INT IDENTITY(1,1) PRIMARY KEY,
Name NVARCHAR(50) NOT NULL
);
若直接运行以下语句，会收到错误提示：
INSERT INTO dbo.Users (Id, Name) VALUES (100, '张三'); -- 消息 544，级别 16：当 IDENTITY_INSERT 设置为 OFF 时，不能为表 'Users' 中的标识列插入显式值。
这个限制的本质是防止人为破坏自增连续性，导致后续自动生成的值与已有数据冲突。但在可控场景下，SQLServer提供了正规渠道来临时接管标识列写入权。
二、方法一：使用SET IDENTITY_INSERT开关
最常用也最安全的方式是开启会话级的SET IDENTITY_INSERT。该开关仅对当前连接有效，且同一时刻同一张表只能有一个会话设为ON。开启后，必须在INSERT中写出完整的列列表，并显式包含标识列。
示例代码如下，先打开开关，插入指定Id，再关闭开关：
SET IDENTITY_INSERT dbo.Users ON; INSERT INTO dbo.Users (Id, Name) VALUES (100, '张三'); SET IDENTITY_INSERT dbo.Users OFF;
这种方法的优点是语义清晰、权限要求低（只需要表所有者或ALTER权限），并且不会改动表本身的种子定义。缺点是必须成对书写ON与OFF，遗忘关闭可能导致同连接后续隐式插入失败；同时并发写入其他会话若也要显式插入，会相互阻塞。
插入完成后，建议检查当前最大标识值，避免下次自动插入撞上刚写的100：
SELECT MAX(Id) FROM dbo.Users; -- 若 MAX(Id) 大于当前种子，应手动调整，见下文 DBCC CHECKIDENT
三、方法二：用DBCC CHECKIDENT重置标识种子
如果批量导入历史数据后，希望后续自增从最大值之后开始，可以使用DBCC CHECKIDENT重新设定当前标识值。它不直接允许插入，而是修改系统记录的当前值，从而让自动生成的值绕开已占用的区间。
常见用法是先插入（借助IDENTITY_INSERT），再执行以下命令让种子与数据对齐：
DBCC CHECKIDENT ('dbo.Users', RESEED, 100);
-- 下一个自动生成的 Id 将是 101
该命令也可用于清空表后归位：传入RESEED加比基值小的数，配合TRUNCATE可重置自增。但需要注意，在含外键引用的表上TRUNCATE会失败，且DBCC属管理员命令，部分云数据库受限。误用RESEED可能造成主键重复，因此应在维护窗口执行并备份。
对比SET IDENTITY_INSERT，DBCC CHECKIDENT更偏向“事后修正”，而前者是“事中插入”。二者经常组合使用，先写旧值，再调种子，保证链路不断。
四、方法三：临时表绕行与ETL思路
当没有权限执行IDENTITY_INSERT，或源数据极度混乱时，可创建一张结构相同但不带标识列的临时表，先把数据落盘，再通过INSERT SELECT转入正式表（此时正式表标识列不出现在列列表，由系统赋值）。
示例脚本：
CREATE TABLE #Users_stage
(
Id INT PRIMARY KEY,
Name NVARCHAR(50) NOT NULL
);
INSERT INTO #Users_stage (Id, Name)
VALUES (101, '李四'), (102, '王五');
-- 正式表不写 Id，由标识列自动生成新值
INSERT INTO dbo.Users (Name)
SELECT Name FROM #Users_stage;
DROP TABLE #Users_stage;这种方式牺牲了原Id，换取了免权限插入，适合只需内容、不要求保留原主键的报表迁移。若必须保留原Id，仍要回到方法一。实际ETL中，也可借助SSIS的“启用标识插入”选项，其底层同样是IDENTITY_INSERT。
五、方法对比与选型建议
为方便选型，将三种方案放在一张表里比较：
| 方案 | 是否保留原标识值 | 所需权限 | 典型场景 |
|---|---|---|---|
| SET IDENTITY_INSERT | 是 | 表ALTER | 补录旧数据、跨库同步 |
| DBCC CHECKIDENT | 否（仅调种子） | DBA | 导入后防断号 |
| 临时表绕行 | 否 | 普通写权限 | 无标识插入权限的内容迁移 |
日常维护中，推荐优先使用SET IDENTITY_INSERT并在同一事务内完成开关与写入，既明确又可控。若涉及大量历史区间，写完后务必用DBCC CHECKIDENT核对，防止后续自增主键报错。临时表方案仅作为权限受限时的兜底。
注意：标识列不等于主键，但常作主键。即便标识列允许显式插入，唯一约束依然生效，重复值会被拒绝。
掌握上述写法后，SQLServer标识列插入便不再神秘。无论是修复数据还是构建测试环境，都能按业务需要平稳操作。
SQLServer标识列SET_IDENTITY_INSERT修改时间：2026-08-07 11:36:32