Hibernate为何将MySQL默认ID生成策略改为TABLE？

1. 为何从AUTO切换到TABLE策略？ #

Hibernate的AUTO策略会自动适配数据库原生自增方案（MySQL对应IDENTITY，依赖AUTO_INCREMENT）。切换到TABLE策略的核心原因包括：

• 跨数据库兼容性需求，这是最核心的动机；
• 全局ID统一管控，适配分库分表、多数据源场景下的全局唯一ID需求；
• 官方优化支持，通过批量预生成ID减少数据库交互次数，应对高并发场景。

2. TABLE策略在MySQL的明确优势？ #

优势是场景化的，并非绝对：

• 零成本跨库移植：如果项目未来需要切换到Oracle、PostgreSQL等数据库，TABLE策略无需修改代码即可兼容，而依赖原生自增的AUTO策略可能因数据库特性差异出现兼容问题；
• 批量插入性能提升：开启批量ID预生成（通过hibernate.id.increment_size设置批量大小）后，Hibernate会一次性从ID生成表获取一批ID并在内存分配，减少网络IO与数据库锁竞争，高并发批量插入场景下吞吐量明显优于原生自增；
• 灵活的ID规则定制：可自定义ID起始值、步长，还能按业务分设不同的ID生成器（如用户、订单表各用独立序列），比原生自增更灵活。

但TABLE策略也有劣势：单条插入场景下会多一次ID查询操作，性能不如原生自增；高并发下ID生成表的行锁竞争若处理不当（如批量大小不合理），反而会成为瓶颈。

3. 是否为了实现跨数据库可移植性？ #

是的，这是TABLE策略设计的核心目标之一。作为ORM框架，跨数据库兼容性是Hibernate的核心特性，TABLE策略完全基于标准SQL操作生成ID，脱离数据库原生ID机制，确保在所有支持JDBC的数据库上都能稳定运行，无需针对不同数据库调整ID生成配置。

4. 有没有实际体验过TABLE策略在MySQL的性能提升？ #

不少开发者在特定场景下确实体验过性能提升：

• 电商订单批量导入、数据批量同步这类场景，设置合理的批量大小（如hibernate.id.increment_size=50）后，TABLE策略的插入吞吐量比原生自增高30%-50%，核心原因是大幅减少了数据库交互次数；
• 但单条插入为主的业务场景中，TABLE策略反而会因多一次ID查询操作变慢。另外，批量大小设置过大可能导致ID浪费，设置过小则无法发挥批量优化的作用，需根据业务场景调整。

额外注意：MySQL中使用TABLE策略时，需将ID生成表的引擎设为InnoDB并为主键加索引，否则锁竞争会加剧，抵消性能优势。

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