提出这个问题,是因为在工作中发现 mysql 中的 user 表的 id 默认是自增的,但是数据库存储的结果却不是连续的。 user 表结构: CREATE TABLE `user` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 递增id, `name` varchar(20), `create_time
提出这个问题,是因为在工作中发现 mysql 中的 user 表的 id 默认是自增的,但是数据库存储的结果却不是连续的。
user 表存储:
1.1 MyISAM 引擎的自增值保存在数据文件中。
1.2 InnoDB 引擎的自增值,其实是保存在了内存里,并且到了 MySQL 8.0 版本后,才有了“自增值持久化”的能力,也就是才实现了“如果发生重启,表的自增值可以恢复为 MySQL 重启前的值”,具体情况是:
根据要插入的值和当前自增值的大小关系,自增值的变更结果也会有所不同。假设,某次要插入的值是 X,当前的自增值是 Y。
新的自增值生成算法是:从 auto_increment_offset 开始,以 auto_increment_increment 为步长,持续叠加,直到找到第一个大于 X 的值,作为新的自增值。其中,auto_increment_offset 和 auto_increment_increment 是两个系统参数,分别用来表示自增的初始值和步长,默认值都是 1。
1 当执行上述 SQL 时,执行器调用 InnoDB 引擎接口写入一行,传入的这一行的值是 (0,"张三"); 2 InnoDB 发现 SQL 没有指定自增 id 的值,获取 user 表当前的自增值 2; 3 将传入的行的值改成 (2,"张三"); 4 将表的自增值改成 3;
5 继续执行插入数据操作。 对于批量插入数据的语句,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开始。 |
2021-06-02
2021-06-05
2022-06-27
2022-10-12
2019-09-11