MAX(id)+1在并发场景下必然失败，因多事务同时读取相同最大值导致重复编号和跳号；SEQUENCE是唯一可靠方案，需正确配置START WITH、CACHE等参数并确保与插入操作同事务执行。
为什么MAX(id)+1在存储过程中必然失败
并发场景下，两个事务同时执行SELECT MAX(id)拿到相同结果，各自加1后插入，编号直接撞车。更糟的是，事务回滚会让这个“已生成”的编号永久丢失，业务上表现为跳号——这不是bug，是设计缺陷。
常见错误现象包括：订单号重复、工单编号冲突、日志流水号断续。这类写法哪怕加了WITH (UPDLOCK, ROWLOCK)，高并发时仍会因间隙锁争抢引发死锁或性能陡降。
- 别用
SELECT TOP 1 id ORDER BY id DESC替代，本质一样 - 别在应用层缓存当前最大值再+1，状态不同步风险极高
- 临时表或堆表上跑这类逻辑，等于没防重
NEXT VALUE FOR + SEQUENCE 是唯一可靠方案
SQL Server 2012+ 原生支持SEQUENCE，它由引擎原子管理，不依赖表数据，天生抗并发、不跳号、可跨表复用。关键参数必须显式指定，否则默认行为极易踩坑：
-
START WITH必须比当前最大编号大1，例如现有最大订单号是9999，就得写START WITH 10000 -
INCREMENT BY 1是常规选择，负数只在倒序编号时才用 -
CACHE 50能显著提升性能，但实例意外重启会丢失最多50个未用编号；若业务零容忍跳号，改用NOCACHE - 务必加
NO CYCLE，否则用尽后从头循环（如9999回到0001），编号直接重复
示例：
CREATE SEQUENCE dbo.OrderNoSeq AS bigint START WITH 10000 INCREMENT BY 1 MINVALUE 1 MAXVALUE 999999999 NO CYCLE CACHE 50;
拼接前缀时最容易浪费序列号
编号逻辑不能拆成“先取序列值 → 再拼字符串 → 再插入”，中间任何环节失败都会导致序列号浪费或状态不一致。正确做法是在INSERT语句里直接调用：
- 纯数字：
INSERT INTO Orders(OrderNo) VALUES(NEXT VALUE FOR dbo.OrderNoSeq) - 带日期前缀（如
ORD202608040001）：INSERT INTO Orders(OrderNo) VALUES('ORD' + FORMAT(GETDATE(), 'yyyyMMdd') + RIGHT('0000' + CAST(NEXT VALUE FOR dbo.OrderNoSeq AS VARCHAR(10)), 4)) -
NEXT VALUE FOR在同一语句中多次调用返回相同值，别写成'ORD' + NEXT VALUE FOR ... + NEXT VALUE FOR ...，否则多消耗一个号
存储过程里调用序列必须处理事务边界
很多人把序列号生成包进存储过程，却忽略错误回滚时序列号已递进但数据未落库，造成空洞。关键点：
- 序列号生成和主表插入必须在同一个事务内，且
INSERT失败时整个事务回滚 - 别在
TRY...CATCH里单独捕获序列相关错误——NEXT VALUE FOR本身几乎不会报错，问题出在后续插入环节 - 如果拼接逻辑复杂，可封装成标量函数，但函数内禁止含
INSERT/UPDATE/DELETE，否则触发Modifying data in a function is not allowed错误
真正容易被忽略的，是序列起始值与现有数据的对齐——迁移或初始化时漏设START WITH，会导致刚上线就撞号。
