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的取值范围为:-231——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性能

你可能感兴趣的:(idea,mysql,数据库,sql)