Hibernate中IDENTITY与步长1的SEQUENCE策略性能对比及价值探讨

核心结论 #

即使是配置为START 1 INCREMENT 1的SEQUENCE，在Hibernate与PostgreSQL的组合中，效率依然优于IDENTITY策略。

为什么步长1的SEQUENCE更高效？ #

• 主键获取时机差异：IDENTITY策略下，主键值由数据库在插入操作完成后生成，Hibernate必须等待插入结束才能拿到主键，这直接导致无法使用JDBC批量插入——批量插入需要提前知晓所有记录的主键值，才能完成关联实体绑定或后续逻辑。而SEQUENCE策略下，Hibernate可以提前从序列获取主键值，插入操作可以攒成批量提交，大幅减少数据库交互次数。
• 锁机制与并发表现：PostgreSQL的IDENTITY（对应SERIAL或GENERATED AS IDENTITY）依赖表级自增计数器，高并发插入时会产生较严重的锁竞争；而SEQUENCE是独立的数据库对象，锁粒度更细，并发场景下的锁等待时间更短，能支撑更高的插入吞吐量。
• Hibernate内置优化兼容：Hibernate的SequenceStyleGenerator（默认启用的序列生成器）对SEQUENCE有原生优化，哪怕序列步长为1，只要Hibernate的allocationSize配置与序列步长匹配，依然可以利用提前生成主键的特性，避免IDENTITY的插入后阻塞问题。

性能提升是否显著？ #

性能差异取决于业务场景：

• 低并发、单条/少量插入场景：两者效率差异不明显，几乎感知不到。
• 高并发、批量插入场景：性能提升会非常显著。比如批量插入1000条数据时，IDENTITY只能逐条提交，而SEQUENCE可以批量提交，减少网络IO和数据库事务开销，同时锁竞争更少，吞吐量能提升数倍。

步长1的SEQUENCE是否无意义？ #

并非如此。哪怕步长为1，SEQUENCE依然具备两个IDENTITY无法替代的优势：

1. 保留了提前生成主键和更优锁粒度的核心特性，在高并发场景下依然比IDENTITY表现更好。
2. 灵活性更高：后续如果业务需要调整步长、共享序列给其他表，或者开启批量插入模式，只需修改序列配置或Hibernate的allocationSize参数即可，无需修改表结构；而IDENTITY要做类似调整，需要修改表的自增字段定义，成本更高。

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