在一些中小型项目开发中，我们通常会使用自增 ID 来作为主键的生成策略，但随着时间的推移，数据库的信息也会越来越多，尤其是使用自增 ID 作为日志表的主键生成策略时，可能很快就会遇到 ID 被用完的情况...PS：当然，在分库分表的场景中，我们通常会使用雪花算法来替代自增 ID，但中小型项目开发中，使用自增 ID 的场景还是比较多的。...1.自增ID 在 MySQL 中，如果字段的数据类型为整数类型（如 INT、BIGINT 等），则可以通过关键字“AUTO_INCREMENT”来设置让当前的字段实现自增，例如以下 SQL： CREATE...1.2 缺点分析自增 ID 的缺点如下： 在数据进行迁移或分库分表时，可能会出现问题，需要特殊处理。 如果数据量非常大，可能会达到自增 ID 的上限。...存在安全性问题，比如通过自增 ID 可能会推测出一些业务信息。例如，一个电商订单表使用自增 ID 作为主键，可能会被竞争对手通过订单号大致推测出业务量等信息。2.自增ID用完会怎样？
我在工作中经常会遇到有人问我，数据库表的ID是自增的，那么如果ID用完了会怎么样？...说实话，我一直从事的是政企行业的开发，因为是传统行业，并且数据量基本上增长缓慢，所以到目前为止我还没遇到过自增ID用完的情况。因此我连夜做了实验，并编写了这篇文章将结果分享出来。...（全文以MySQL为例，因为MySQL最常用） 一、有主键 在MySQL中int类型占4个字符，因为自增ID大部分都是以1开始，所以它的取值范围为1到2^32-1，也就是1到4294967295。...首先我们创建一张表，并设置ID自增，且从2147483647开始。...从这里得知，在有主键且主键自增的情况下，ID达到上限后MySQL会报错。
1.有主键 如果设置了主键，并且一般会把主键设置成自增。...我们知道，Mysql里int类型是4个字节，如果有符号位的话就是[-2^31,2^31-1]，无符号位的话最大值就是2^32-1，也就是4294967295。...也就是说，如果设置了主键并且自增的话，达到自增主键上限就会报错重复的主键key。 解决方案，mysql主键改为bigint，也就是8个字节。...2.没有主键 如果没有设置主键的话，InnoDB则会自动帮你创建一个6个字节的row_id，由于row_id是无符号的，所以最大长度是2^48-1。...如果超过上限row_id会从0重新开始计算 , 覆盖旧数据
他问了我一个有意（keng）思（b）问题： 数据库中的自增 ID 用完了该怎么办？ 这个问题其实可以分为有主键 & 无主键两种情况回答。 国际惯例，先上张脑图： ?...02 有主键 如果你的表有主键，并且把主键设置为自增。 在 MySQL 中，一般会把主键设置成 int 型。...每次插入一条数据，都把全局 row_id 当成主键 id，然后全局 row_id 加 1。 这种情况的数据库自增 ID 用完会发生什么呢？...04 总结 数据库自增主键用完后分两种情况： 有主键，报主键冲突 无主键，InnDB 会自动生成一个全局的 row_id。它到达最大值后会从 0 开始算，遇到 row_id 一样时，新数据覆盖旧数据。...为什么我说这是个有意（keng）思（b）问题？ 我的回答除了以上解决方法外，还提到在业务开发中，我们不会等到主键用完那天就已经分库分表了，基本不会遇到这种情况。
// MySQL replace into导致的自增id问题 // 今天线上遇到一个问题，挺有意思，这里记录一下希望对大家有所帮助。...某个表中，只有一条记录，发生高可用切换之后，自增id的值发生了变化，主从的自增id值不一致，导致数据写入报主键冲突的错误。...此时如果主从库发生切换，那么新插入到从库中的id=6的值就会发生主键冲突了，显示插入不进去，这是我们不想看到的。 那么为什么从库上的自增值和主库不一致呢？...*/; 可以看到，MySQL将replace into的在binlog中保存的格式是update语句，那么update语句本质上不会对自增值进行修改，所以就导致了主从的表自增id不一致，这样虽然看着没有什么问题...，从库的自增id比主库的小，当主从发生切换的时候，这个问题就比较严重了，有些数据写入的时候，就会报错了。
MySQL 主键 自增 ID 会用完吗？...首先我们一般创建 MySQL 数据表的时候，大部分情况下会创建一个自增主键ID 的字段，可能你的建表语句如下： CREATE TABLE IF NOT EXISTS `tb`( `id` INT...所以 在 MySQL 中 自增 ID 是会用完的。那么问题来了，加入他的 ID 用完会发生什么事呢？ 我们来验证下。...如果会那么久需要创建 8 字节的 INT 类型了，他的值最大是 2^64-1 那么问题又来了，你说 我有些业务是不需要主键 、不需要自增编号，我不创建这个字段，就好了，这样想恭喜你 回答错误....总结： 自增 ID 用完 会报主键冲突、数据插入失败。 不指定主键、默认创建的 row_id 会 覆盖原有的数据。
=4 DEFAULT CHARSET=latin1 自增ID为4，删除ID最大的记录并不影响自增ID的值。...MySQL 重启后自增ID从哪儿开始 例如当前表中有ID为1,2,3三条记录，把3删除，重启MySQL，新插入记录的ID从哪儿开始？ 很多人会认为从4开始，实际是从3开始。...重启MySQL。...手动插入ID后，下次插入时自增值是多少 例如当前的自增ID为4，新插入记录时，手动指定ID为10，下次使用自增方式插入时，ID是 11。...删除最大ID值对自增ID值没有影响，但MySQL重启之后有影响，不会使用之前的自增ID值，而是使用最大ID+1，因为自增ID值是存在内存中，重启后需要重新计算。 自增ID用完后就不变了。
今天咱们来看一道数据库中比较经典的面试问题：为什么要使用雪花 ID 替代数据库自增 ID？同时这道题也出现在了浩鲸科技的 Java 面试中，下面我们一起来看吧。...浩鲸科技的面试题如下：其他面试题相对来说比较简单，大部人题目都可以在我的网站上（www.javacn.site）找到答案，这里就不再赘述，咱们今天只聊“为什么要使用雪花 ID 替代数据库自增 ID？”...这个本地时钟会定期与系统时钟进行同步，如果检测到系统时钟往前走了（出现了时钟回拨），则将本地时钟调整为系统时钟。4.为什么要使用雪花 ID 替代数据库自增 ID？...例如，数据库分片之后，会在同一张业务表的分片数据库中产生相同 ID（数据库自增 ID 是由每个数据库单独记录和增加的），这样就会导致，同一个业务表的竟然有相同的 ID，而且相同 ID 背后存储的数据又完全不同...小结数据库自增 ID 只适用于单机数据库环境，而对于分库、分表、数据分片来说，自增 ID 不具备唯一性，所以要要使用雪花 ID 来替代数据库自增 ID。
浩鲸科技的面试题如下： 其他面试题相对来说比较简单，大部人题目都可以在我的网站上（www.javacn.site）找到答案，这里就不再赘述，咱们今天只聊“为什么要使用雪花 ID 替代数据库自增 ID...这个本地时钟会定期与系统时钟进行同步，如果检测到系统时钟往前走了（出现了时钟回拨），则将本地时钟调整为系统时钟。 4.为什么要使用雪花 ID 替代数据库自增 ID？...数据库自增 ID 只适用于单机环境，但如果是分布式环境，是将数据库进行分库、分表或数据库分片等操作时，那么数据库自增 ID 就有问题了。...例如，数据库分片之后，会在同一张业务表的分片数据库中产生相同 ID（数据库自增 ID 是由每个数据库单独记录和增加的），这样就会导致，同一个业务表的竟然有相同的 ID，而且相同 ID 背后存储的数据又完全不同...小结 数据库自增 ID 只适用于单机数据库环境，而对于分库、分表、数据分片来说，自增 ID 不具备唯一性，所以要要使用雪花 ID 来替代数据库自增 ID。
作者 | 陌无崖 转载请联系授权 引言 今天在写项目的时候学习了一个用代码编写的自增的数据库ID，其实是一个ID缓冲池。使用了golang中chan类型。...AUTO_INCREMENT COMMENT '自增主键', `business_id` varchar(128) COLLATE utf8mb4_bin NOT NULL COMMENT '业务...COLLATE=utf8mb4_bin COMMENT='分布式自增主键'; -- ---------------------------- -- Records of uid -- -------...首先从数据库中加载获得当前数据的最大值 循环生成自增ID func (u *Uid) produceId() { // 从数据库中获取id u.reload() for {...= nil { return err } u.min = maxId u.max = maxId + step return nil } 有了这个数据库自增
缺点：获取的不是真正的自增id，是表中最大的Id，如果有删除数据的话，那么该值和自增id相差比较大。如果有连表数据，有可能导致数据错乱。...使用LAST_INSERT_ID函数：select LAST_INSERT_ID() 优点：获取到的是真正的自增id。 缺点：该函数是与table无关的，永远保留最新插入的自增列的id。...使用mysql查询函数：SHOW TABLE STATUS; 优点：能够准确的查到自增id。而且可以在语句后面加上where语句或者like语句来过滤。...---- mysql自增id的重置 使用truncate：truncate table； 说明：使用truncate会删除表的数据释放空间，并且重置字自增id，但不会删除表的定义。...也不会清空数据，有可能会出现重复key的可能，所以此方法也只适用于清空表之后重置自增id或者大量删除后修改自增id。
问题排查 这张表是一个简单的接口服务在使用，每天大数据会统计一大批信息，然后推送给小A，小A将信息更新到数据库中，如果是新数据就插入，旧数据就更新之前的数据，对外接口就只有查询了。...也就是说，上面的语句，会跟REPLACE INTO ...类似的会将自增ID加1，但实际记录没有加，这是为什么呢?...查了资料之后，小A得知，原来，mysql主键自增有个参数innodb_autoinc_lock_mode，他有三种可能只0,1,2，mysql5.1之后加入的，默认值是1，之前的版本可以看做都是0。...ON DUPLICATE KEY UPDATE ...的话，你会发现auto_increment并没有增加，因为这种模式直接加了AUTO_INC锁，执行完语句的时候释放，发现没有增加行数的话，不会增加自增...删除表的自增主键 删除自增主键，让唯一索引来做主键，这样子基本不用做什么变动，只要确定目前的自增主键没有实际的用处即可，这样的话，插入删除的时候可能会影响效率，但对于查询多的情况来说，小A比较两种之后更愿意选择后者
面试官：咱们聊聊mysql的自增id。...mysql自增id给我们的自增主键定义带来了很大的方便，但是经常mysql的自增id会有不连续情况，能说说什么场景下mysql的id会产生不连续吗我：我以一张表为例来解释一下，我先创建一张表zh_person...我：如果id的值是0或者null的话，id也会自增的。...，但是id的值还是增加了1，为什么这么说呢，我们修改上面的语句如下，插入成功后表里面虽然有4条记录，但是id是1、2、3、5 INSERT INTO zh_person(NAME, sex,id_no)...面试官：等一下，mysql的自增id在唯一索引冲突的时候为什么不会回滚回去呢？
当我们使用 MySQL 进行数据存储时，一般会为一张表设置一个自增主键，当有数据行插入时，该主键字段则会根据步长与偏移量增长（默认每次+1）。...自增的值并不是保存在表结构信息内的，对于不同的版本它们有如下的区别： 1.1.1 MySQL 8.0版本之前（重启后可能会产生变化）： 计数器的值存储在内存中的，重启后丢弃，下一次将读取最大的一个自增ID...且当 Binlog 模式为 statement（SBR）时自增 ID 不能保证数据的正确性 1.5 自增 ID 一定就是连续吗？...不一定，业务也不应该过分依赖 MySQL 自增 ID 的连续性，在以下三种情况下，并不能保证自增 ID 的连续性： 1.5.1 插入时的其他唯一索引冲突 假设已存在数据{1,张三}，且张三所属的字段设置了唯一主键...当我们为表设置了自增主键后，自增 ID 的范围则与主键的数据类型长度相关。
需求： 已有的mysql数据表，希望增加一个自增的字段，并设置新数据的初始值。 实际上不复杂，只是做个备忘。...新数据的起始值 /*增加一个自增主键字段，分两步操作*/ /*首先增加自增字段*/ alter table t_abc add column id int auto_increment primary...key; /*执行完上面这一条，字段增加，但值为空*/ /*执行这一条，它会自动为已存在的数据的自增字段赋初值，从1开始，同时将后续新增的数据从100开始*/ alter table t_abc auto_increment...key; /*这里没有指定任何数值，执行完后只为自增字段赋从1开始的初始值，其实隐含的设置当前表自增字段从1开始*/ alter table t_abc auto_increment; /*将所有数据增加...10000*/ update t_abc set id=id+10000; /* 前面的100 我们是任意指定的，现在我们应该指定数据库中的maxId+1作为下一个数据的起始值*/ set @maxId
问题 对于MySQL表，如果自增ID不是主键时，是否可以用来做增量查询？ 2. ...背景 需要按照自增ID字段进行增量查询，有些表的自增ID是主键，而有些表的自增只是普通索引，有些采用MyISAM，有些采用InnoDB。... BY f_id”会极影响查询效率。...// 按自增ID有序（自增ID为主键） MySQL [test]> SELECT * FROM tableA1; +----+----+----+----+ | id | af | bf | cf |...ID为主键时，自增ID乱序插入，查询结果也是按自增ID有序（实测有序插入一样有序），因此可以放心依自增ID增量查询，而不必指定“ORDER BY f_id”。
这些都是题外话，只是告诉你数据量大了是有可能达到上限的而已，回到Mysql自增ID上限的问题，可以分为两个方面来说。 1.有主键 如果设置了主键，并且一般会把主键设置成自增。...也就是说，如果设置了主键并且自增的话，达到自增主键上限就会报错重复的主键key。 解决方案，mysql主键改为bigint，也就是8个字节。...因为我们先设置row_id=1开始，所以1，2，3的row_id也是1，2，3。 修改row_id为上限值之后，row_id会从0重新开始计算，所以4，5，6的row_id就是0，1，2。...总结 自增ID达到上限用完了之后，分为两种情况： 如果设置了主键，那么将会报错主键冲突。...如果没有设置主键，数据库则会帮我们自动生成一个全局的row_id，新数据会覆盖老数据 解决方案： 表尽可能都要设置主键，主键尽量使用bigint类型，21亿的上限还是有可能达到的，比如魔兽，虽然说row_id
我们都知道表的主键一般都要使用自增 id，不建议使用业务 id ，是因为使用自增 id 可以避免页分裂。这个其实可以相当于一个结论，你都可以直接记住这个结论就可以了。...但是如果你要弄明白什么是页分裂，或者什么情况下会页分裂，这个时候你就需要对 mysql 的底层数据结构要有一定的理解了。...如果主键为自增 id 的话，mysql 在写满一个数据页的时候，直接申请另一个新数据页接着写就可以了。...如果主键是非自增 id，为了确保索引有序，mysql 就需要将每次插入的数据都放到合适的位置上。...其实对主键 id 还有一个小小的要求，在满足业务需求的情况下，尽量使用占空间更小的主键 id，因为普通索引的叶子节点上保存的是主键 id 的值，如果主键 id 占空间较大的话，那将会成倍增加 mysql
不同的引擎对于自增值的保存策略不同： MyISAM引擎的自增值保存在数据文件中 InnoDB引擎的自增值保存在内存里，但是在MySQL8.0以后，该自增值才可以被持久化：MySQL5.7以前，自增值没有持久化每次重启后第一次打开表的时候...，会找自增值的最大值max(id)，然后将最大值加1作为这个表的自增值；MySQL8.0版本会将自增值的变更记录在redo log中，重启时依靠redo log恢复。...事务回滚为什么自增值不能回退 两个并行的事务在申请自增值的时候，为了避免两个事务申请到相同的自增id，需要加锁按照顺序申请，如果自增值可以回退需要做一些特殊处理： 每次申请id之前，判断表里此id是否存在...（去主键索引树上判断该id是否存在） 把自增id的锁范围扩大，必须等到一个事务提交后才，下一个事务才可以申请id，锁粒度太大，系统并发能力极大下降 为了避免上述的性能消耗，InnoDB即使语句执行失败也不回退自增...，那就在需要的时候申请1个，如果有10w行数据那就需要申请10万次，对于批量插入数据的语句，MySQL有一个批量申请自增id的策略： 语句执行过程中，第一次申请自增id，分配1个 1个用完以后，第二次申请
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
