springboot - 为什么用户名重复时数据库自增主键没有回滚到预期状态？

Question

我写了一个注册用户的接口和处理用户名相同的异常，当抛出这个异常的时候做事务回滚，现在我使用postman对我这个接口测试的时候，正常注册并插入数据库没有问题，但是当用户名相同的时候，id(自增主键)并没有像我学习的回滚那样1->3，而是1->2，我打开日志也显示是已经回滚，我现在不知道为什么会出现这样的情况

我认为当事务回滚的时候，自增主键id是不连续的状态而不是连续的

Answer 1

自增主键（AUTO_INCREMENT）的递增机制与事务回滚的关系需要从数据库底层机制来理解：

1. 自增主键的分配机制
   自增主键的递增发生在插入操作时，而不是事务提交时。当执行INSERT语句时：
2. 数据库会立即预分配下一个自增ID
3. 这个分配操作本身是事务无关的
4. 即使事务回滚，已分配的自增值也不会被回收

5. 事务回滚的作用范围
   事务回滚可以保证：
   ✓ 已插入的数据行会被删除
   ✓ 表锁/行锁会被释放
   ✓ 但不会回滚以下内容：

   • 自增计数器的当前值
   • 已分配的序列号（如Oracle的sequence）
   • 某些数据库的缓存预分配机制
6. 不同数据库的具体表现
7. MySQL InnoDB：自增值永久递增（内存中维护计数器）
8. PostgreSQL：使用序列(SEQUENCE)，默认也不会回退
9. SQL Server：类似行为，自增值不连续

10. **验证实验（以MySQL为例）：

    START TRANSACTION;
    INSERT INTO users (username) VALUES ('test'); -- 分配id=2
    ROLLBACK; 
    INSERT INTO users (username) VALUES ('test'); -- 实际得到id=3

11. 解决方案建议
    如果需要连续ID：
12. 不要依赖自增主键的连续性（不符合数据库设计原则）
13. 改用程序生成的UUID或其他分布式ID方案
14. 定期使用ALTER TABLE重置自增值（不推荐，存在并发风险）
15. 业务层应对
16. 主键应该仅作为唯一标识符，不承载业务逻辑
17. 需要连续编号时应单独建立业务流水号字段
18. 通过定期维护任务清理不连续的空隙（如果有必要）

这是数据库的标准设计行为，目的是保证主键分配的原子性和高性能。自增主键的连续性不是事务的保证范围，而是需要根据具体业务需求选择合适的主键生成策略。