TRUNCATE TABLE 在 SQL Server 中默认重置自增标识（IDENTITY），但需确认是否真正执行成功；若未重置，常见原因是误用 DELETE、存在锁阻塞、启用 KEEPIDENTITY 选项（SQL Server 2022+/Azure）、或误判 IDENT_CURRENT 返回值——该函数返回历史最大值而非下一次插入值，正确验证方式是插入新行观察 ID 是否从 1 开始。
TRUNCATE TABLE 在 SQL Server 中默认会重置自增标识（IDENTITY）——如果没重置，说明触发了异常条件或你误判了现象。
TRUNCATE 后 IDENTIY 没变？先确认是不是真没重置
常见误判场景：你执行了 TRUNCATE TABLE t，然后立刻查 SELECT IDENT_CURRENT('t') 或 DBCC CHECKIDENT('t', NORESEED)，发现返回值还是原来的最大 ID。这不是 TRUNCATE 失效，而是这两个函数查的是“当前已分配的最大值”，不是“下一次插入将用的值”。真正反映重置结果的是下一条 INSERT 的 ID。
- 正确验证方式：插入一行新数据，看
id是不是从 1（或定义的SEED）开始 -
IDENT_CURRENT()返回最后生成的标识值，哪怕表空着也返回历史最大值 -
DBCC CHECKIDENT('t', NORESEED)显示的是当前“种子+增量”状态，不等于下一次插入值
哪些情况会导致 TRUNCATE 不重置 IDENTITY？
SQL Server 的 TRUNCATE TABLE 在绝大多数情况下都会重置 IDENTITY 计数器，但以下情况例外：
- 表被其他会话以
NOLOCK或未提交事务持有架构锁（Sch-S），TRUNCATE 可能被阻塞或降级为逻辑删除（极罕见，多见于高并发或锁争用） - 使用了
KEEPIDENTITY选项（仅限 Azure SQL Database 和 SQL Server 2022+，且需显式指定：TRUNCATE TABLE t WITH (KEEPIDENTITY)） - 表是临时表（
#t）但创建后被多个批处理引用，某些版本中缓存行为可能导致标识状态残留（建议显式加DBCC CHECKIDENT('t', RESEED, 1)确保） - 你实际执行的是
DELETE FROM t而非TRUNCATE TABLE t（尤其在脚本里混用、或 IDE 自动补全错误）
SQL Server 中重置 IDENTITY 的可靠写法
如果你已经 TRUNCATE 了但不确定是否生效，或想强制确保归零，直接用 DBCC CHECKIDENT：
DBCC CHECKIDENT ('t', RESEED, 1);
注意：
- 该命令不会清空数据，只重置计数器；必须配合
TRUNCATE或DELETE使用才有意义 - 如果表非空，
RESEED值必须 ≥ 当前最大 ID + 1，否则下次插入会报主键冲突（SQL Server 不校验该约束） - 对分区表、有复制或 CDC 的表，
DBCC CHECKIDENT可能被禁止或需额外权限
和 MySQL / PostgreSQL 的关键区别别搞混
SQL Server 的 TRUNCATE 行为是明确且稳定的：只要没加 KEEPIDENTITY，就重置。但其他数据库不同：
- MySQL：没有
KEEPIDENTITY选项，TRUNCATE总是重置AUTO_INCREMENT（除非外键阻止执行） - PostgreSQL：
TRUNCATE默认不重置序列，必须写TRUNCATE TABLE t RESTART IDENTITY - 别把
ALTER TABLE t AUTO_INCREMENT = 1（MySQL）或ALTER SEQUENCE ... RESTART WITH 1（PG）套用到 SQL Server —— 它没有这类语法
真正容易被忽略的是：TRUNCATE 是否成功执行了。检查日志或用 @@ROWCOUNT 确认影响行数，比盯着 IDENT_CURRENT 更可靠。
