【原创】杂谈自增主键用完了怎么办

引言

在面试中，你们应该经历过以下场景

面试官:"用过mysql吧，大家是用自增主键仍是UUID？"
你:"用的是自增主键"
面试官:"为何是自增主键？"
你:"由于采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla..."
面试官:"那自增主键达到最大值了，用完了怎么办？"
你:"what，没复习啊！！"
(而后，你就能够回去等通知了！)

这个问题是一个粉丝给我提的，我以为挺有意(KENG)思(B)!
因而，今天咱们就来谈一谈，这个自增主键用完了该怎么办！

正文

简单版

咱们先明白一点，在mysql中，Int整型的范围以下

类型	最小值	最大值	存储大小
Int(有符号)	-2147483648	2147483648	4 bytes
Int(无符号)	0	4294967295	4 bytes

咱们以无符号整型为例，存储范围为0～4294967295，约43亿！咱们先说一下，一旦自增id达到最大值，此时数据继续插入是会报一个主键冲突异常以下所示

//Duplicate entry '4294967295' for key 'PRIMARY'

那解决方法也是很简单的，将Int类型改成BigInt类型，BigInt的范围以下

类型	最小值	最大值	存储大小
BigInt(有符号)	-9223372036854775808	9223372036854775808	8 bytes
BigInt(无符号)	0	18446744073709551615	8 bytes

就算你每秒10000条数据，跑100年，单表的数据也才
10000*24*3600*365*100=31536000000000
这数字距离BigInt的上限还差的远，所以你将自增ID设为BigInt类型，你是不用考虑自增ID达到最大值这个问题！
然而，若是你在面试中的回答若是是

你:"简单啊，把自增主键的类型改成BigInt类型就行了！"

接下来，面试官能够问你一个更坑的问题！

面试官:"你在线上怎么修改列的数据类型的？"
你:"what！我仍是回等通知吧！"

怎么改

目前业内在线修改表结构的方案，据我了解，通常有以下三种
方式一:使用mysql5.6+提供的在线修改功能
所谓的mysql本身提供的功能也就是mysql本身原生的语句，例如咱们要修改原字段名称及类型。

mysql> ALTER TABLE table_name CHANGE old_field_name new_field_name field_type;

那么，在mysql5.5这个版本以前，这是经过临时表拷贝的方式实现的。执行ALTER语句后，会新建一个带有新结构的临时表，将原表数据所有拷贝到临 时表，而后Rename，完成建立操做。这个方式过程当中，原表是可读的，不可写。可是会消耗一倍的存储空间。
在5.6+开始，mysql支持在线修改数据库表，在修改表的过程当中，对绝大部分操做*，原表可读，也能够写。
那么，对于修改列的数据类型这种操做，原表还能写么？来来来，烟哥特地去官网找了mysql8.0版本的一张图

如图所示，对于修改数据类型这种操做，是不支持并发的DML操做！也就是说，若是你直接使用ALTER这样的语句在线修改表数据结构，会致使这张表没法进行更新类操做(DELETE、UPDATE、DELETE)。
所以，直接ALTER是不行滴！

那咱们只能用方式二或者方式三
方式二:借助第三方工具
业内有一些第三方工具能够支持在线修改表结构，使用这些第三发工具，可以让你在执行ALTER操做的时候，表不会阻塞！比较出名的有两个

• 一、pt-online-schema-change，简称pt-osc
• 二、GitHub正式宣布以开源的方式发布的工具，名为gh-ost

以pt-osc为例，它的原理以下

• 一、建立一个新的表，表结构为修改后的数据表，用于从源数据表向新表中导入数据。
• 二、建立触发器，用于记录从拷贝数据开始以后，对源数据表继续进行数据修改的操做记录下来，用于数据拷贝结束后，执行这些操做，保证数据不会丢失。
• 三、拷贝数据，从源数据表中拷贝数据到新表中。
• 四、rename源数据表为old表，把新表rename为源表名，并将old表删除。
• 五、删除触发器。

然而这两个有意(KENG)思(B)的工具，竟然。。。竟然。。。唉！若是你的表里有触发器和外键，这两个工具是不行滴！
若是真碰上了数据库里有触发器和外键，只能硬杠了，请看方式三
方式三:改从库表结构，而后主从切换
此法极其麻烦，须要专业水平的选手进行操做。由于咱们的mysql架构通常是读写分离架构，从机是用来读的。咱们直接在从库上进行表结构修改，不会阻塞从库的读操做。改完以后，进行主从切换便可。惟一须要注意的是，主从切换过程当中可能会有数据丢失的状况！

高深版

其实答完上面的问题后，这篇文章差很少完了。可是，还记得我在开头说的么。这是一个颇有意(KENG)思(B)的问题，为何呢？
假设啊，你的表里的自增字段为有符号的Int类型的，也就是说，你的字段范围为-2147483648到2147483648。
一切又那么恰好，你的自增ID是从0开始的，也就是说，如今你的能够用的范围为0～2147483648。
咱们明确一点，表中真实的数据ID，确定会出现一些意外，ID不必定是连续的。例如，有以下情形的出现

CREATE TABLE `t` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`),
) ENGINE=InnoDB;

执行下列SQL

insert into t values(null);
// 插入的行是 (1)
begin;
insert into t values(null);
rolllack;
insert into t values(null);
// 插入的行是 (3)

所以，表中的真实id必然会出现断续的状况。
好，那这会你的自增主键id的数据范围为0～2147483648，也就是单表21亿条数据！考虑id会出现断续，真实数据顶多18亿条吧。
老哥，都单表18亿条了，还不分库分表？你一旦分库分表了，就不能依赖于每一个表的自增ID来全局惟一标识这些数据了。此时，咱们就须要提供一 个全局惟一的ID号生成策略来支持分库分表的环境。所以，你须要关注的文章是《分库分表后如何上线部署》

所以在实际中，你根本等不到自增主键用完到情形！
因此，专业版回答以下

面试官:"那自增主键达到最大值了，用完了怎么办？" 你:"这问题没遇到过，由于自增主键通常用int类型，通常达不到最大值，咱们就分库分表了，因此未曾碰见过！"