如果你是拿 IDEA 或 DataGrip 连 SQL Server，想从旧库里搬点数据，或者就是手痒想往一张带自增列的表里插入一条指定 ID 的记录，大概率会碰到下面这行报错：
When IDENTITY_INSERT is set to OFF, you cannot insert explicit value for identity column in table 'xxx'.
这句话看着挺长，翻译过来其实就一句话：你正在给自增列（标识列）手动填充值，但 SQL Server 默认不允许这么干。很多人在查询控制台里被它卡了一下午，还有人是在 DataGrip 的表格编辑器里添加新行时莫名其妙被拦住。我最初在 DataGrip 里从 Excel 批量粘贴数据时也栽过一次，后来把 IDENTITY_INSERT 的机制彻底搞明白，就再也没有被这个报错恶心过。
这篇文章适合所有用 IDEA 或 DataGrip 连 SQL Server 做数据维护、数据迁移的开发者。读完你不仅能解决眼前这个报错，还能搞清楚为什么会有这个限制、什么时候该开开关、什么时候千万不要开，以及常见的坑长什么样。
1. 报错本身和背后的机制
1.1 具体报错长什么样
这个错误在 SQL Server 平台上常见的中文提示是：
当 IDENTITY_INSERT 设置为 OFF 时，无法为表 'dbo.users' 中的标识列插入显式值。
英文原话通常有两种写法：
When IDENTITY_INSERT is set to OFF, you cannot insert explicit value for identity column in table 'xxx'.Cannot insert explicit value for identity column in table 'xxx' when IDENTITY_INSERT is set to OFF.
不管字母顺序怎么变，它都指向同一个问题：你执行了一条 INSERT 语句，并且这条语句包含了自增列的显式值。
举个例子，假设dbo.users表里有一个id字段，定义是IDENTITY(1,1)。你写了一条很普通的插入语句：
INSERT INTO dbo.users (id, name, email) VALUES (1001, '张三', 'zhangsan@example.com');只要id是自增列，这一条语句就会触发上面的报错。因为id由数据库自己管理，正常情况下 SQL Server 不允许你往里面塞指定的数字。
在 DataGrip 里，这个报错可能出现在两个地方：一个是你打开查询控制台自己敲 SQL，另一个是你用表格编辑器可视化添加数据。IDEA 自带 Database 工具其实和 DataGrip 同源，报错逻辑基本一致。很多人一开始没意识到原因，以为是工具配置问题，其实工具只是把你的操作转换成 INSERT 语句，真正拦你的是数据库引擎。
1.2 IDENTITY_INSERT 是干什么的
SQL Server 里的自增列，正式名称叫“标识列”或“标识列属性”，由IDENTITY(种子, 步长)定义。比如IDENTITY(1,1)表示从 1 开始，每次加 1。数据库会自动生成下一跳值，你不需要也不应该手动指定。
但现实世界里总有一些特殊需求必须要手动指定 ID，最常见的就是数据迁移。比如你从旧系统导入用户数据，这些用户 ID 可能被订单表、日志表引用过，如果把 ID 重新生成，外键关系就全断了。这时候就必须让新表保留原来的 ID 值。
为了解决这个矛盾，SQL Server 提供了一个会话级开关：
SET IDENTITY_INSERT dbo.users ON;打开这个开关后，当前会话里就可以向dbo.users的标识列插入显式值。插入完成后，再关掉：
SET IDENTITY_INSERT dbo.users OFF;这个开关有几个非常关键的脾气：
- 它是会话级的，只对当前连接有效，不影响其他连接。
- 同一时刻，一个会话只能对一张表开启。
- 开启期间，如果你插入一条不带 ID 的普通记录，反而会报错，因为此时数据库要求必须为标识列提供显式值。
这些特性直接决定了后面所有操作的正确姿势。
1.3 为什么会在 IDEA / DataGrip 里踩到这个坑
如果你是在 SSMS 里面遇到这个报错，很容易想到去查 IDENTITY_INSERT 的用法。但在 IDEA 或 DataGrip 里，很多人会把它误认为“工具问题”。
真实原因通常是下面三种场景：
第一种是你在查询控制台里直接写了手动带 ID 的 INSERT。这类场景最常见，特别是导入脚本、补数据脚本，写着写着就把 ID 列写进去了。
第二种是你在表格编辑器里手动添加数据。DataGrip 双击表名会打开数据编辑器，表里所有列都会显示出来，包括自增 ID 列。你如果手一抖在 ID 列表格里填了数字，工具生成的 INSERT 语句就会包含该列，于是报错。
第三种是复制粘贴带过来的。比如你从 Excel 复制几行数据到 DataGrip 的表格编辑器，或者你在工具里复制已有记录然后修改，ID 列的值也会被一起复制过来。提交时就会撞上同一个错误。
这里要注意一个容易忽略的细节：DataGrip 每次打开一个“查询控制台”，默认就是同一个连接会话。但如果你开了多个控制台，它们可能对应不同的连接。在控制台 A 里设置IDENTITY_INSERT ON，去控制台 B 执行 INSERT，照样报错。这是很多人排查半天没找到原因的经典陷阱。
2. 动手前先做的三个判断
2.1 确认你插入的是不是标识列
解决报错前，先别急着打开开关，确认一下你正在插的到底是不是真正的标识列。
SQL Server 里“主键”和“标识列”是两个概念。主键保证唯一性，标识列负责自动生成数字。一个表可以有主键但没有任何自增列，也可以有自增列但没建主键。只有带IDENTITY属性的列才受这个限制。
你可以在 DataGrip 里直接看表结构：右键表名 → Modify Table，或者展开表字段列表，看目标列有没有“标识”相关属性。更严谨一点，可以直接跑一段 SQL：
SELECT COLUMNPROPERTY(OBJECT_ID('dbo.users'), 'id', 'IsIdentity') AS IsIdentity;返回 1，就说明这一列是标识列。如果返回 0，那你的报错可能不是这个原因，得回去检查权限、表名或者数据类型。
还有一点，SQL Server 的标识列一般是数字类型，比如int、bigint、smallint等。如果你用一个非自增的字段保存固定主键，比如订单号是varchar，那手工指定值完全没问题，不需要开这个开关。
2.2 判断你到底需不需要手动指定 ID
确认是标识列之后，下一个问题是：这个 ID 你非填不可吗？
大部分实际场景里，你根本不需要指定 ID。比如在测试环境加一条用户数据，只要保证姓名、邮箱、状态这些业务字段正确，ID 让数据库自己生成就行。这种情况下，最简单的解决方式不是开SET IDENTITY_INSERT，而是直接删掉 ID 列，让 INSERT 语句不包含它。
用 SQL 写就是这样：
INSERT INTO dbo.users (name, email) VALUES ('李四', 'lisi@example.com');因为省略了自增列，SQL Server 会自动生成 ID，报错自然消失。如果你是在 DataGrip 表格编辑器里操作，就手动把 ID 单元格的值清空，留空或显示为“默认值”，提交时工具就不会把 ID 带进 INSERT。
但遇到这两类情况，你就必须保留指定 ID：
- 数据迁移/数据恢复：要从旧表把原 ID 搬到新表，并且要保持和关联表的关系。
- 固定业务标识：某些系统约定 ID 必须从指定数字开始，或者存在外部数据已经引用了这个 ID。
只有在这种明确需要显式 ID 的场景下，才轮到IDENTITY_INSERT上场。
2.3 权限、会话和 SQL Server 的硬性限制
开SET IDENTITY_INSERT不是随便一个账号都能执行的。你需要至少具备目标表的ALTER权限。
经验上，db_owner或sysadmin角色都够，但如果你只有db_datareader和db_datawriter，执行 SET 语句大概率会失败。Azure SQL Database 之类的云数据库，也至少需要相应的ALTER权限或更高的角色。权限不足时，你会在控制台看到类似The user does not have permission to perform this action的报错。
这个开关还是典型的“会话级设置”，并且有唯一性限制。同一时刻，一个会话中只能有一张表处于IDENTITY_INSERT ON状态。如果你试图对第二张表也开启同一个开关，SQL Server 会直接甩给你一个错误：
IDENTITY_INSERT is already ON for table 'xxx'. Cannot perform SET operation for table 'yyy'.
所以，你需要先关闭前一张表，再开启当前表。每次操作都在同一个连接里完成，不要跨控制台分开执行。
另外，SET IDENTITY_INSERT是会话状态，不是事务状态。我的建议是：无论你是否在事务中执行插入，都养成“用完立刻关”的习惯，不要依赖会话自动断开去清理。
3. 在 IDEA / DataGrip 里的两种解决方案
3.1 方案一：SQL 命令方式（最通用）
这是我要给的最推荐做法，适合批量插入、脚本导入、以及所有能写 SQL 的场景。
打开一个查询控制台，执行以下脚本：
SET IDENTITY_INSERT dbo.users ON; INSERT INTO dbo.users (id, name, email) VALUES (1001, '张三', 'zhangsan@example.com'); INSERT INTO dbo.users (id, name, email) VALUES (1002, '李四', 'lisi@example.com'); SET IDENTITY_INSERT dbo.users OFF;这段脚本做了三件事：先打开开关，然后插入两条指定 ID 的数据，最后关闭开关。
有几个细节要特别注意：
dbo这个 schema 前缀尽量别省。如果表不在默认 schema 下，不带前缀可能找错对象。- 多条 INSERT 可以放在同一个脚本里连续执行，不需要每条语句都去开关一次。
- 整个脚本最好在一个查询控制台里从头到尾执行，不要拆成多条手动运行。
如果你开启了事务，可以写成这样：
SET IDENTITY_INSERT dbo.users ON; BEGIN TRANSACTION; INSERT INTO dbo.users (id, name, email) VALUES (1001, '张三', 'zhangsan@example.com'); COMMIT TRANSACTION; SET IDENTITY_INSERT dbo.users OFF;这样数据插入和开关都在同一会话、同一批次内完成。执行完最后一行的OFF后，你再执行普通的、不带 ID 的 INSERT，就不会被额外的规则干扰。
在 DataGrip 中执行整个脚本，建议直接用“运行当前文件”或者选中所有语句后运行，而不只是一次运行一条。因为如果你只运行了第一行SET IDENTITY_INSERT ON，然后又分开去运行 INSERT，虽然同一个控制台里状态还在，但万一手滑刷新了连接，状态就丢了。
3.2 方案二：图形编辑器方式（绕过显式 ID）
如果你是新手，或者不太想把 SQL 玩明白，直接在 DataGrip 里用表格编辑器也行，但必须记住一条：ID 列留空。
具体操作是这样的：
- 在数据库工具窗口找到目标表，双击表名，打开表格编辑器。
- 点击“添加行”按钮，或者直接在最后一行往下填。
- 正常填写姓名、邮箱等业务字段。
- 看到 ID 那一列，不管它显示什么，都别填数字，把它留空。
- 提交数据。
DataGrip 生成 INSERT 语句时，看到 ID 列没有值，就会自动省略这个字段，生成的 SQL 类似于：
INSERT INTO dbo.users (name, email) VALUES (?, ?)这样就不会碰到IDENTITY_INSERT报错。
但如果你是从 Excel 复制数据，或者复制了已有记录再修改，ID 列往往被自动填上了值。这时候你必须手动把那列内容清空，再提交。千万别以为 ID 列填个空字符串就行，而是要清除单元格内容，让整个单元格处于空或默认状态。
如果你需要在图形编辑器里保留原 ID，那还是不建议用表格编辑器直接提交。老老实实切到查询控制台，用方案一的方式开开关。因为表格编辑器一旦包含了 ID 列，生成的 INSERT 就一定会撞上限制，你也没有地方在编辑器里写SET IDENTITY_INSERT。
3.3 如何在 DataGrip / IDEA 里高效执行这些操作
DataGrip 里打开查询控制台非常简单：右键目标表 → 选择“Open In Console”或“Query Console”，也可以直接在工具栏点击“Open Console”。IDEA 自带的 Database 工具操作逻辑类似，只不过入口在右侧 Database 窗口。
控制台打开后，你可以把上面那段 SQL 直接复制进去。对比 DataGrip 的代码补全，表名和字段都会自动提示，写起来很方便。
如果你是频繁做数据补录的，建议把下面这个模板保存成 SQL 文件，下次直接改表名和值就行：
USE [your_database]; SET IDENTITY_INSERT dbo.users ON; -- 在这里粘贴你的 INSERT 语句 SET IDENTITY_INSERT dbo.users OFF;不过要提一句：如果你打开新的控制台，相当于打开了新的连接会话。在旧控制台开启的IDENTITY_INSERT，不会作用到新控制台。所以模板脚本里写了USE [your_database]，也算是一种保险，确保连接到正确的库。
DataGrip 的表格编辑器适合快速查看和简单修改，但需要指定 ID 的批量插入，始终是在 SQL 控制台里更顺手。这也是我后来一直采用的方式：可视化编辑负责查，SQL 脚本负责插，两者配合。
4. 高频问题排查与避坑实录
4.1 高频问题速查表
我在公司和社区里经常看到很多朋友被同一个问题绕晕，这里整理成一张表，直接对照着看：
| 报错或现象 | 原因 | 正确做法 |
|---|---|---|
| 手动给自增列填值报 IDENTITY_INSERT OFF | INSERT 语句包含标识列 | 开SET IDENTITY_INSERT ON，用完 OFF |
| 开启 ON 后，不带 ID 的普通 INSERT 也报错 | ON 状态下强制要求提供显式值 | 先执行SET IDENTITY_INSERT OFF |
| 对另一张表开启 ON 时报“ID已经ON” | 同一会话只能有一张表处于 ON | 先把上一张表 OFF |
| 执行 SET 语句提示权限不足 | 当前账号缺少 ALTER 权限 | 换有更高权限的账号，或申请权限 |
| 另一个控制台里 INSERT 仍然报错 | SET 是会话级，跨连接不生效 | 在同一个控制台完整执行全套脚本 |
| DataGrip 表格编辑器添加行报错 | ID 列被填了值时生成的 SQL 包含显式值 | 清空 ID 列内容再提交 |
这张表我遇到过的频率从高到低排列，前两行占了 80% 的日常问题。
4.2 三个我亲自踩过或看同事踩过的坑
第一个坑是：开启了IDENTITY_INSERT ON之后，忘记关闭开关，接着用程序或者工具插入一条不带 ID 的新数据，结果收到这样一条错误：
Explicit value must be specified for identity column in table 'dbo.users' when IDENTITY_INSERT is set to ON.
当时我还纳闷：明明以前这样插没问题，怎么现在要求必须显式提供 ID？查了一圈才发现，原来是刚才执行测试脚本时开了开关没关。ON状态下，数据库会反过来要求你“必须提供 ID”，和普通状态完全相反。从那以后，我每次写完脚本都会再扫一眼，确认最后一行是OFF。
第二个坑和 DataGrip 表格编辑器有关。有一次我要导入一批新用户，Excel 数据里包含旧系统导出的 ID 字段。我复制粘贴到 DataGrip 的编辑器里，所有列原封不动填好了，一提交就报错。当时第一反应是数据格式问题，后来才发现是因为 ID 列被 Excel 一起粘进来了。解决办法也很简单：把 ID 列整个清空，让它自动生成。如果确实需要保留原 ID，那就切成 SQL 脚本来做。
第三个坑是权限问题。我有个同事拿到的数据库账号只有读写数据的权限，平时查表、改数据都正常，但执行SET IDENTITY_INSERT ON时被拒绝。这类操作看起来和数据无关，但它需要ALTER权限，不是所有普通读写账号都具备的。如果你发现 SQL 语句没错、会话也没问题，但执行 SET 时被拒绝，第一反应就该去看权限。
4.3 记忆关键词：用完就 OFF
关于这个报错，很多东西不需要死记硬背，你只要记住一个原则就可以解决绝大多数问题：
该自动生成的时候，别手动指定 ID；不得不手动指定 ID 的时候，把 SET IDENTITY_INSERT 打开，插完立刻关掉。
更进一步说：
- 不需要指定 ID → INSERT 语句里不要带标识列。
- 需要指定 ID → 同一连接里先打开开关，再执行 INSERT，最后关闭。
- 一个会话只允许开一张表 → 换表操作前先关掉上一张。
我在实际使用中还有一个习惯：所有涉及IDENTITY_INSERT的脚本，都会在注释里写明“这段脚本执行完后必须关闭开关”。因为人总有手滑的时候，尤其是批量操作多的时候。脚本一多，很容易忘了哪段开了、哪段没关。留个注释，或者在脚本结构上强制写成“ON、INSERT、OFF”三段式，能少踩很多坑。
如果你用的是 DataGrip 或 IDEA 的表格编辑器，最简单粗暴的规避方式就是别碰 ID 列。只要你不给标识列填值，这个错误就永远不会出现。真碰上需要保留原 ID 的迁移场景，再想起今天的SET IDENTITY_INSERT ON / OFF，就不会再被英文报错吓到了。
