JPA @SequenceGenerator生成主键跳号不连续的原因与解决方法

这个现象和JPA注解配置无关，是数据库序列的固有设计特性导致的：

• 数据库序列是独立于业务表的非事务性对象，每次调用序列的nextval接口获取值时，序列的计数推进操作会立刻持久化，不会绑定外层业务事务的回滚逻辑。
• JPA在持久化实体时，会在执行insert语句之前就先申请序列值赋值给实体主键。后续不管是因为唯一约束冲突、字段非空校验失败、代码抛出异常导致事务回滚，已经被取走的序列值都不会被归还，直接产生跳号。你遇到的插入重复数据被唯一约束拦截、id=2被消耗的场景，完全符合这个逻辑。
• 你配置的allocationSize = 1只是关闭了Hibernate预取批量序列值的优化，不会解决插入失败、事务回滚带来的序列消耗问题。
• 顺序错乱出现在并发场景：不同事务获取序列值的顺序，和事务最终提交落表的顺序没有强绑定关系。比如事务A先拿到id=2，但是执行慢/后续回滚，事务B拿到id=3后先提交成功，表中就会先出现id=3的记录，看起来就是顺序错乱。

结论非常明确：如果要保证主键100%连续无任何缺口，不要使用数据库序列、IDENTITY自增这类原生主键生成策略。
所有数据库内置的自增、序列机制都是设计成"取值即消耗"，天生不保证连续。如果硬要实现完全连续，只能通过手动加锁取max(artist_id) + 1的方式生成主键：

• 这种方案在并发写入时必须加表级排他锁，避免两个事务同时拿到同一个id，会直接把写入吞吐量压到极低的水平，生产环境完全不适用。
• 哪怕你把所有校验逻辑都提前，也没法100%避免跳号：数据库宕机、网络中断、事务意外回滚等异常场景依然会消耗id产生缺口。

• 先纠正认知：主键的核心作用是唯一标识一行数据，本身不承载业务含义，跳号不会影响数据一致性、查询性能、业务逻辑，属于完全正常的情况，不需要专门修复。
• 如果你的业务需要对外展示连续编号（比如艺人编码、订单流水号），不要直接使用主键作为展示编号。单独新增一个业务编号字段，在事务成功提交后再按规则生成连续值，和主键完全解耦。
• 如果想尽可能减少无意义的跳号，可以把字段格式校验、重复值校验这类逻辑提前到持久化操作之前，在申请序列值之前就拦截无效请求，降低无效的序列消耗，但不需要追求完全无缺口。

内容的提问来源于stack exchange，提问作者nikolaPantelic98