mysql自动递增的id

mysql的表id自动递增

在于自增主键的分配，是由InnoDB数据字典内部一个计数器来决定的，而该计数器只在内存中维护，并不会持久化到磁盘中。当数据库重启时，该计数器会通过下面这种方式初始化。SELECT MAX(ai_col) FROM table_name FOR UPDATE;
重启后以最后新增的最大id为准，
未重启则内存中的为主

mysql清除自增从1开始

 alter table 表名 auto_increment = 1;

关于主键id用完了

主键id用完，分成两种情况，分别为有主键或无主键 并且如果达到用完前还没进行分库分表只有… 回答是没遇到过早都分表了 但是解决的话就是以下

1、有主键

解决方案修改类型 在mysql，int整型的范围如下int的取值范围为：-2^31——231-1，即-2147483648—2147483647
修改成将Int类型改为BigInt类型，BigInt的范围如下-2^63-1 到2^63-1，也就是-9223372036854775808 到9223372036854775807

就算每秒往数据表插入10000条数据，运行100年，来看看数据量有多少

10000243600365100=31536000000000

这数字距离BigInt的上限还差的远，再问领导收拾行李滚蛋了么 还不分表分库

--修改表字段类型  
alter table 表名字 change 字段名字  字段名字 bigint;

需要注意的是，这种方式在myl5.6+才开始支持，mysql支持在线修改数据库表，在修改表的过程中，对绝大部分操作，原表可读，也可以写。
PS：单表 21 亿的数据量显然不现实，一般来说数据量达到 500 万就该分表了。

2、无主键

mysql没有主键的话会出现不报主键冲突但是会覆盖你的数据原因如下

实际上 InnoDB 维护了一个全局的 dictsys.row_id，所以未定义主键的表都共享该 row_id，并不是单表独享。每次插入一条数据，都把全局 row_id 当成主键 id，然后全局 row_id 加 1。

---

mysql为什么不用uuid等不连续来作为id

1、回答一

因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间。这个过程需要做很多额外的操作，数据的毫无顺序会导致数据分布散乱，将会导致以下的问题：

①：写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机IO

②：因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据，一次插入最少需要修改三个页以上

③：由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片

在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又需要一定的时间消耗。
2、回答二

mysql在innodb的存储引擎下是使用B+树来做为索引的数据结构的，而一个表最终必定会创建一个主键索引，即是没有设置主键也会有生成规则（先查找有没有非空的唯一索引，没有则可以使用默认的rowid字段创建索引）我们知道索引采用B+树的结构后，数据必须是有序的，如果此时page1已经写满，page2写了一半，当下一个数据是有序的时候，则数据将直接追加到page2的末尾。

如果数据是无序的，那么数据可能被插入到page1的某个位置，但是此时page1已经写满了，那么page1中插入数据后面的数据就必须往后移动，存不下的数据就只能放到其他的page，此时就发生了page的分裂和合并，如果此时page2也是写满的，那么将依次影响其他的page，那么将大大影响数据的插入和删除，这就是主键索引不适合使用UUID的原因
主键不适合使用无序字段的原因：
1、无序字段作为索引会导致page的分裂与合并
2、UUID等数据占用字节数太多，而自增的int类型只需要占用4个字节，所有索引最终都会在叶子节点存储主键的id，会导致占用更多的磁盘空间以及降低io性能