为何触发ConstraintViolationException后数据库自增ID仍会递增？

一、原因定位 #

这个现象完全是MySQL的自增主键（AUTO_INCREMENT）机制导致的，和JDBC、JPA、Hibernate都没有关系。

MySQL处理自增列的逻辑是：当执行INSERT语句时，会先从自增计数器里获取下一个可用的ID值，分配给当前要插入的记录，之后才会执行约束检查、数据写入等操作。如果此时触发唯一约束（比如重复name）导致插入失败，事务会回滚，但已经被预分配的自增ID不会被收回——因为MySQL的自增计数器是独立于事务的，这样设计是为了减少并发插入时的锁竞争，提升整体写入性能。

二、是否属于正常行为 #

这是MySQL的正常设计行为，并非bug。官方文档明确说明：自增列的值不会因为事务回滚而回退，这种“ID间隙”是为了换取更好的并发性能而做出的权衡。

三、解决办法 #

1. 从根源避免重复插入（推荐） #

最直接的方式是避免触发唯一约束异常，同时避免ID浪费：

• 使用INSERT ... ON DUPLICATE KEY UPDATE语句，当遇到重复键时，要么更新现有记录，要么做无意义的更新（比如更新为原值），这样既不会抛出异常，也不会消耗自增ID：

  INSERT INTO department(name) VALUES ('研发部') ON DUPLICATE KEY UPDATE name = name;
  

• 在业务层先做唯一性校验，再执行插入，但要注意并发场景下可能存在校验后插入前的间隙，所以最好结合数据库的唯一约束和上述SQL语句双重保障。

2. 接受ID间隙（无成本方案） #

如果业务对ID的连续性没有强制要求，只是觉得间隙不美观，完全可以不用处理。自增ID的核心作用是作为记录的唯一标识，连续性并不是必须的属性。

3. 更换主键生成策略（不推荐，除非必要） #

如果业务强要求ID绝对连续，可以考虑更换主键生成策略：

• 改用GenerationType.TABLE：Hibernate会用一张专门的表来维护主键序列，事务回滚时会释放已分配的ID，保证连续性，但这种方式的性能比IDENTITY差很多，不适合高并发场景。
• 注意：MySQL 5.7及之前不支持原生序列，GenerationType.SEQUENCE会被Hibernate模拟为表序列，本质和TABLE策略类似；MySQL 8.0+支持原生序列，但序列本身也不会因为事务回滚而回退，所以同样会有间隙。

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