MySql自增主键ID重置这个坑货

ゝ一世哀愁。 2023-03-04 09:19 6阅读 0赞

这两天在面试的时候被问到一个问题：在mysql中用自增列作为主键时，先往表里插入5条数据，此时表里数据id为1、2、3、4、5，如果此时删除id=4、5的数据后，再重启数据库，重启成功后向表里insert数据的时候，INNODB、MyISAM引擎下ID分别是从几开始增加？当时被问到这个问题时，一脸懵逼，MD谁有事没事去重启线上数据库嘛。最后还是基础知识不牢固，在此作个笔记。

MySQL通常使用的引擎都是INNODB，在建表时，一般使用自增列作为表的主键，这样的表对提高性能有一定的帮助。但是自增列有一个坑，并且这个坑存在了很久，一直到MySQL 8.0版本，才修复了这个坑，这个坑就是表的自增列变量auto\_increment在MySQL重启后，有可能丢失。

*  **innodb引擎(低版本)：Innodb表中把自增列作为主键ID时，自增列是通过auto-increment计数器实现的，计数器的最大值是记录到内存中的，重启数据库后，会导致auto-increment计数器重置，从而会导致主键ID重置。**
 *  **MyISam引擎：MyISAM表会把自增列(auto-increment计数器)最大值是记录到数据文件里，重启MySQL自增列(计数器)最大值不会丢失，从而使用自增列作为主键ID时也不会丢失。**

# **1.innodb主键重置问题** #

在 MySQL低版本中，InnoDB表中使用自增的 auto-increment计数器 会把值存放在内存中，不会写入磁盘。一旦MySQL 服务重启，这个值就丢了，InnoDB 引擎会根据表中现有的数据重新计算该计数器的值：获取表中最大的自增主键ID作为auto-increment计数器的最大计数，当insert数据时，在auto-increment计数器最大值上1。

先创建一张user表，新增几条数据：

//1.创建user表：自增列作为主键ID
    CREATE TABLE `user` (
      `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
      `name` varchar(255) NOT NULL DEFAULT '',
      `age` int(4) unsigned NOT NULL DEFAULT '0',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
    
    //2.插入5条数据
    INSERT INTO `user`(`name`, age) VALUES('刘备1', 21);
    INSERT INTO `user`(`name`, age) VALUES('刘备2', 22);
    INSERT INTO `user`(`name`, age) VALUES('刘备3', 23);
    INSERT INTO `user`(`name`, age) VALUES('刘备4', 24);
    INSERT INTO `user`(`name`, age) VALUES('刘备5', 25);

## **(1)场景一** ##

**mysql数据库不重启时，innodb自增主键ID会根据auto-increment计数器一直递增。**

向user表里插入5条数据，主键ID按自增列通过auto-increment计数器实现自增。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70][]

在user表里删除id为4、5的数据，再向user表中插入一条数据，主键ID是auto-increment的值6。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 1][]

## **(2)场景二** ##

**mysql数据库重启后，innodb自增主键ID会根据auto-increment计数器的重置而重置。**

在场景一的基础上，在删除id为6、3的数据后，此时auto-increment计数器的值为7，user表里的id最大是2。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 2][]

然后重启数据库后，auto-increment计数器的值变为3，也就是user表里的自增列ID的最大值2加1。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 3][]

此时在插入数据时，自增ID会从3开始自增。Innodb表中把自增列作为主键ID时，在mysql重启后就会存在ID重置问题。**删除数据后，再重启，AUTO\_INCREMENT会查询表里最大ID并进行重置，重置后和重启前AUTO\_INCREMENT计数器的值不同。**在MyISAM引擎表中的自增列不会存在这个问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 4][]

# **2.MySQL 8.0 auto-increment 计数器逻辑** #

在 MySQL 8.0 中，这个计数器的逻辑变了：每当计数器的值有变，InnoDB 会将其写入 redo log，保存到引擎专用的系统表中。MySQL 正常关闭后重启：从系统表中获取计数器的值。MySQL 故障后重启：从系统表中获取计数器的值；从最后一个检查点开始扫描 redo log 中记录的计数器值；取这两者的最大值作为新值。

# 3.总结 #

**（1）如果mysql重启了，那么innodb表在启动后，AUTO\_INCREMENT值会自动检测出、并重置为当前表中自增列的最大值+1。**

**（2）假如一个表里AUTO\_INCREMENT计数器的值是10，此时执行update table set id = 15 where id = 9后，如果这时再继续插入数据，到了自增ID=15的时候是会报错。但是这个时候继续插入，就不会报错。因为刚才即使报错了，AUTO\_INCREMENT的值依旧会增加。**

（3）现在使用的一般都是innodb引擎，如果将myisam引擎转换过来的时候，一定要小心这个引擎在自增id上的不同表现。在主从使用不同引擎的时候,也会出现问题,最好将引擎改完一致性的。

参考：《[Be Careful With MySQL's auto\_increment. How We Ended Up Losing Data][Be Careful With MySQL_s auto_increment. How We Ended Up Losing Data]》

2020年08月03号 早 于 北京记

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70]: /images/20230208/3887f19fe66a4d208185f9f15f15be8f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 1]: /images/20230208/5b6b3935e9e1481ca6c3321e8abbb2cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 2]: /images/20230208/06a4c7c34b3c4015a0ebd6586a285983.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 3]: /images/20230208/b7bb448a9c914e508ad6ac2f8556c0ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Nla3lfZmVp_size_16_color_FFFFFF_t_70 4]: /images/20230208/9907932233604e56a1de1bf827c8f38c.png
[Be Careful With MySQL_s auto_increment. How We Ended Up Losing Data]: https://desmart.com/blog/be-careful-with-mysql-s-auto_increment-how-we-ended-up-losing-data