Mysql自增ID你所不知道的那些事
如果你使用频繁的是Mysql数据库，不妨了解下下面的这些问题，或许，在你下一次跳槽面试中就会用到。
为什么要使用自增ID作为主键？
我们在设计表结构的时候，唯一不可缺少的字段就是ID，这样有助于我们操作表，或者和别的表进行关联。
所以我们为了方便就会使用自增主键，在设计数据库时不需要费尽心思去考虑设置主键问题考虑唯一性问题。
对InnoDB来说
1: 主键索引既存储索引值，又在叶子节点中存储行的数据，也就是说数据文件本身就是按照b+树方式存放数据的。
2: 如果没有定义主键，则会使用非空的UNIQUE键做主键 ; 如果没有非空的UNIQUE键，则系统生成一个6字节的rowid做主键;
聚簇索引中，N行形成一个页（一页通常大小为16K)。如果碰到不规则数据插入时，为了保持B+树的平衡，会造成频繁的页分裂和页旋转，插入速度比较慢。所以聚簇索引的主键值应尽量是连续增长的值，而不是随机值(不要用随机字符串或UUID)。
故对于InnoDB的主键，尽量用整型，而且是递增的整型。这样在存储/查询上都是非常高效的。
那自增主键达到最大值了，用完了怎么办？
我们先明白一点，在mysql中，Int整型的范围如下:
我们以无符号整型为例，存储范围为0～4294967295，约43亿！我们先说一下，一旦自增id达到最大值，此时数据继续插入是会报一个主键冲突异常如下所示：
//Duplicate entry '4294967295' for key 'PRIMARY'
那解决方法也是很简单的，将Int类型改为BigInt类型，BigInt的范围如下：
就算你每秒10000条数据，跑100年，单表的数据也才
10000*24*3600*365*100=31536000000000
这数字距离BigInt的上限还差的远，因此你将自增ID设为BigInt类型，你是不用考虑自增ID达到最大值这个问题！因此，当自增ID用完了可以改成Bigint
那么问题来了你在线上怎么修改列的数据类型的？
怎么改
目前业内在线修改表结构的方案，据我了解，一般有如下三种
方式一: 使用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为例，它的原理如下
1、创建一个新的表，表结构为修改后的数据表，用于从源数据表向新表中导入数据。
2、创建触发器，用于记录从拷贝数据开始之后，对源数据表继续进行数据修改的操作记录下来，用于数据拷贝结束后，执行这些操作，保证数据不 会丢失。
3、拷贝数据，从源数据表中拷贝数据到新表中。
4、rename源数据表为old表，把新表rename为源表名，并将old表删除。
5、删除触发器。
然而这两个有意(KENG)思(B)的工具，居然。。。居然。。。唉！如果你的表里有触发器和外键，这两个工具是不行滴！
如果真碰上了数据库里有触发器和外键，只能硬杠了，请看方式三
方式三: 改从库表结构，然后主从切换
此法极其麻烦，需要专业水平的选手进行操作。因为我们的mysql架构一般是读写分离架构，从机是用来读的。我们直接在从库上进行表结构修改，不会阻塞从库的读操作。改完之后，进行主从切换即可。唯一需要注意的是，主从切换过程中可能会有数据丢失的情况！回到原始问题，自增ID用完了怎么办
假设我们插入的数据是不连续的，实际也是这样的，我们对同一表中的数据删除后，他不会增加的时侯是不会使用这个ID增加的，因此你的自增主键id的数据范围为0～2147483648，也就是单表约21亿条数据！考虑id会出现断续，真实数据顶多15亿条吧。
那么，老哥，单表的数据都达到15亿条了，你的查询列表是不是要几分钟才能转转转出来啊，还不分库分表？你一旦分库分表了，就不能依赖于每个表的自增ID来全局唯一标识这些数据了。此时，我们就需要提供一 个全局唯一的ID号生成策略来支持分库分表的环境。
因此在实际中，你根本等不到自增主键用完到情形！
