sql server的identity列跳号是缓存机制导致的正常现象，非bug；默认开启identity cache以提升并发性能，但异常中断或事务回滚会丢失已分配id，且无法重用，禁用需权衡性能代价。
SQL Server 的 IDENTITY 列跳号不是 bug，而是缓存机制在异常中断时的必然结果——只要没关缓存，就一定会丢号。
IDENTITY CACHE 是什么，为什么默认开启
从 SQL Server 2012 起，IDENTITY 值不再每次 INSERT 都写日志取下一个值，而是预分配一段（如 INT 类型默认预取 1000 个），存在内存中批量使用。这能显著减少闩锁争用和日志写入，提升高并发插入性能。
但代价很直接：一旦进程崩溃、实例意外终止（比如 SHUTDOWN WITH NOWAIT）、或 AlwaysOn 故障转移，这部分已分配但未写入磁盘的 ID 就永久丢失，重启后从下一个缓存块起始值继续分配。
-
INT类型跳号差值通常是 1000（但不绝对，压力大时可能提前刷盘，实际 GAP 可能更小） -
BIGINT类型跳号差值通常是 10000 - 这个缓存大小不可配置，只与数据类型强绑定
事务回滚会不会导致跳号
会，而且非常隐蔽——哪怕事务没提交，只要触发了 IDENTITY 值生成，它就算被“消耗”了。
例如：
BEGIN TRAN;
INSERT INTO orders (product) VALUES ('A'); -- 此时 ID=1001 已分配
INSERT INTO orders (product) VALUES ('B'); -- 此时 ID=1002 已分配
ROLLBACK;
再执行 INSERT INTO orders (product) VALUES ('C');，新 ID 是 1003，不是 1001。因为回滚不归还已分配的标识值。
- 显式
SET IDENTITY_INSERT ON插入也不会影响缓存计数 - 唯一能“重用”ID 的方式是手动
DBCC CHECKIDENT(..., RESEED, ...)，但生产环境严禁随意调低
怎么确认当前是否启用了 IDENTITY CACHE
不是看版本，而是查实时配置。SQL Server 2017+ 支持数据库级开关，老版本只能靠全局跟踪标志。
执行以下语句查看当前数据库的设置：
USE <yourdbname>; SELECT name, value, value_for_secondary FROM sys.database_scoped_configurations WHERE name = 'IDENTITY_CACHE';</yourdbname>
- 返回
value = 1表示开启（默认）；value = 0表示关闭 - 若查询无结果，说明是 SQL Server 2016 或更早版本，此时只能通过
DBCC TRACESTATUS(272)查跟踪标志 -
value_for_secondary = 1在 AG 环境中表示辅助副本也同步该设置
禁用跳号的实操选择与代价
没有零成本方案。所有“禁止跳号”的做法都以牺牲某方面为前提：
- 加启动参数
-t272：全局禁用缓存，所有数据库生效，需重启服务；但会回归到每次 INSERT 都要日志+闩锁，高并发插入性能明显下降 - 数据库级关闭：
ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF；仅限 SQL Server 2017+，粒度更细，但仍影响该库所有表的插入吞吐 - 改用
SEQUENCE：可设NO CACHE，完全可控；但需手动NEXT VALUE FOR，且不支持像IDENTITY那样自动绑定列 - 业务层生成编号：最灵活，但失去数据库原生主键保障，需额外处理并发和唯一性
真正容易被忽略的一点：即使关掉缓存，IDENTITY 在事务回滚时依然跳号——这是设计使然，跟缓存无关。所以，把自增列当业务单号用，本身就是误用。
