阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 blog.csdn.net/jack1liu/article/details/99699201 「新猿一马」欢迎转载，保留摘要，谢谢！

• 一 前言
• 二 自增值存储说明
• 三 自增值修改机制
• 四 自增值修改时机
• 五 导致自增值不连续的原因
  • 5.1 唯一键冲突
  • 5.2 事务回滚
  • 5.3 批量写库操作
• 六 参考文档

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

一 前言

提出这个问题，是因为在工作中发现 mysql 中的 user 表的 id 默认是自增的，但是数据库存储的结果却不是连续的。

user 表结构：

CREATE TABLE `user` ( 
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '递增id', 
 `name` varchar(20),
 `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', 
 `update_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间', 
 PRIMARY KEY (`id`),UNIQUE KEY `idx_name` (`name`)) 
ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='user表'

user 表存储：

二 自增值存储说明

1.1.MyISAM 引擎的自增值保存在数据文件中。

1.2.InnoDB 引擎的自增值，其实是保存在了内存里，并且到了 MySQL 8.0 版本后，才有了“自增值持久化”的能力，也就是才实现了“如果发生重启，表的自增值可以恢复为 MySQL 重启前的值”，具体情况是：

• 在 MySQL 5.7 及之前的版本，自增值保存在内存里。每次重启后，第一次打开表的时候，都会去找自增值的最大值 max(id)，然后将 max(id) + 1 作为这个表当前的自增值。
• 在 MySQL 8.0 版本，将自增值的变更记录在了 redo log 中，重启的时候依靠 redo log 恢复重启之前的值。

三 自增值修改机制

在 MySQL 里面，如果字段 id 被定义为 AUTO_INCREMENT，在插入一行数据的时候，自增值的行为如下：

• 如果插入数据时 id 字段指定为 0、null 或未指定值，那么就把这个表当前的 AUTO_INCREMENT 值填到自增字段；
• 如果插入数据时 id 字段指定了具体的值，就直接使用语句里指定的值。

根据要插入的值和当前自增值的大小关系，自增值的变更结果也会有所不同。假设，某次要插入的值是 X，当前的自增值是 Y。

• 如果 X<Y，那么这个表的自增值不变；
• 如果 X≥Y，就需要把当前自增值修改为新的自增值。

新的自增值生成算法是：从 auto_increment_offset 开始，以 auto_increment_increment 为步长，持续叠加，直到找到第一个大于 X 的值，作为新的自增值。其中，auto_increment_offset 和 auto_increment_increment 是两个系统参数，分别用来表示自增的初始值和步长，默认值都是 1。

四 自增值修改时机

insert into user values(null, '张三');

1. 当执行上述 SQL 时，执行器调用 InnoDB 引擎接口写入一行，传入的这一行的值是 (0,"张三")；
2. InnoDB 发现 SQL 没有指定自增 id 的值，获取 user 表当前的自增值 2；
3. 将传入的行的值改成 (2,"张三");
4. 将表的自增值改成 3；
5. 继续执行插入数据操作。

五 导致自增值不连续的原因

5.1 唯一键冲突

假设执行 SQL 的时候 user 表 id = 10，此时在内存中的自增 id 为11，此时发生唯一键冲突写库失败，则 user 表没有 id = 10 这条记录，之后 id 从11开始写入，因此 id 是不连续的。

5.2 事务回滚

假设同时需要对 user、staff 表进行写库操作，执行 SQL 的时候 user 表 id = 10，此时在内存中的自增 id 为11；staff 表 id = 20，此时内存中的自增 id 为21，一旦事务执行失败，事务回滚，写库失败，则 user 表没有 id = 10 这条记录，staff 表没有 id = 20 这条记录，user 表从11开始写入，staff 表从21开始写入，如此产生 id 不连续的现象。

5.3 批量写库操作

对于批量插入数据的语句，MySQL 有一个批量申请自增 id 的策略：

1. 语句执行过程中，第一次申请自增 id，会分配 1 个；
2. 1 个用完以后，这个语句第二次申请自增 id，会分配 2 个；
3. 2 个用完以后，还是这个语句，第三次申请自增 id，会分配 4 个；

依此类推，同一个语句去申请自增 id，每次申请到的自增 id 个数都是上一次的两倍。

假设批量往 user 表中写入四条记录，则这四条记录将分为三次申请id，

第一次分配到 id = 1，第二次分配到 id = 2、3 ，第三次分配到 id = 4、5、6、7，当批量写入四条记录之后，id = 1、2、3、4将会入库，但是 id = 5、6、7就被废弃了，下一个 id 从8开始。

六 参考文档

• https://time.geekbang.org/column/intro/139