(默认值是1)开始,以auto_increment_increment(默认值是1)为步长,持续叠加,直到找到第一个大于X的值,作为新的自增值 唯一键冲突导致自增主键不连续 insert into t...事务回滚导致自增主键不连续 set autocommit=0; begin; insert into t values(null, 2, 2); rollback; show create table...批量插入导致自增值不连续 自增值锁不是一个事务锁,每次申请完就释放,方便其他事务获取自增值。...,那就在需要的时候申请1个,如果有10w行数据那就需要申请10万次,对于批量插入数据的语句,MySQL有一个批量申请自增id的策略: 语句执行过程中,第一次申请自增id,分配1个 1个用完以后,第二次申请...id的不连续。
自增值的不连续情况 1....因此,InnoDB 放弃了这个设计,语句执行失败也不回退自增 id。也正是因为这样,所以才只保证了自增 id 是递增的,但不保证是连续的。...自增锁的优化 自增 id 锁并不是一个事务锁,而是每次申请完就马上释放,以便允许别的事务再申请 在 MySQL 5.0 版本的时候,自增锁的范围是语句级别。...批量申请自增 id 策略 语句执行过程中,第一次申请自增 id,会分配 1 个; 1 个用完以后,这个语句第二次申请自增 id,会分配 2 个; 2 个用完以后,还是这个语句,第三次申请自增 id,会分配...4 个; 依此类推,同一个语句去申请自增 id,每次申请到的自增 id 个数都是上一次的两倍。
//自增主键不连续的几种情况// 最近在极客时间上学习丁奇大佬的《MySQL 45讲》,这里结合自己的理解分享出来,喜欢的同学可以购买原版课程进行学习,里面的内容很丰富。...02 事务回滚导致的自增键不连续 当我们使用回滚事务的时候,如果该事务内部使用了自增值,那么同样会导致表自增主键出问题,示例如下: mysql> insert into t values (null...03 MySQL自增锁优化带来的不连续 在MySQL5.7中,参数innodb_autoinc_lock_mode被用来控制自增锁的模式,该参数可以设置为三个值:0、1、2. a、当该值为0的时候,...,第二次申请2个自增id 3、2个id用完了,第三次申请4个自增id 例如,我们看下面这个例子: mysql> truncate table t; Query OK, 0 rows affected (...为了避免自增id不连续而造成的主从数据不一致,线上环境,建议设置成innodb_autoinc_lock_mode=2 ,并且 binlog_format=row.这样做,既能提升并发性,又不会出现数据一致性问题
自增列的生成 over()里不带排序或order by 1是一样的效果 select row_number() over() as id,a1.id,relationwords,relation_words...商务手表 Time taken: 34.197 seconds, Fetched: 19 row(s) 方式2: select row_number() over(order by 1) as id...,a1.id,relationwords,relation_words from ods.ods_wpt_management_search_relation_words_full_1d a1 lateral...select row_number() over() + t2.max_id as id, t1.name from (select name from nametb) t1 cross join (...select coalesce(max(id),0) max_id from id_test) t2;
// MySQL replace into导致的自增id问题 // 今天线上遇到一个问题,挺有意思,这里记录一下希望对大家有所帮助。...某个表中,只有一条记录,发生高可用切换之后,自增id的值发生了变化,主从的自增id值不一致,导致数据写入报主键冲突的错误。...=3,age=3这条记录,然后插入id=6,age=3这条记录,自增值变为7....*/; 可以看到,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用完后就不变了。
maybeEmitEvent(new BeforeSaveEvent(objectToSave, dbDoc, collectionName)); Object id...insertDBObject(collectionName, dbDoc, objectToSave.getClass()); populateIdIfNecessary(objectToSave, id...onAfterSaveEvent maybeEmitEvent(new AfterSaveEvent(objectToSave, dbDoc, collectionName)); } 实现mongo自增...id 提供一个@MongoAutoId的注解,然后onBeforeConvert事件中进行转换。...event.getCollectionName())); } } }); } } /** * 获取自增id
但实际上,MySQL 的自增主键并不能保证一定是连续递增的。...理解了 MySQL 自增值到底保存在哪里以后,我们再来看看自增值的修改机制,并以此引出第一种自增值不连续的场景。...也就是说,出现了自增主键不连续的情况。...回退回去的话不就不会发生自增 id 不连续了吗? 事实上,这么做的主要原因是为了提高性能。 我们直接用反证法来验证:假设 MySQL 在事务回滚的时候会把自增值改回去,会发生什么?...自增值不连续场景 4 对于批量插入数据的语句,MySQL 有一个批量申请自增 id 的策略: 语句执行过程中,第一次申请自增 id,会分配 1 个; 1 个用完以后,这个语句第二次申请自增 id,会分配
REPLACE TRIGGER TG_CSMSCLIENTLOGININFO BEFORE INSERT ON CSMS_CLIENT_LOGIN_INFO FOR EACH ROW WHEN (new.id...is null) begin select SEQ_CSMSCLIENTLOGININFO.nextval into:new.id from dual; end;
start with 21 increment by 1 cache 20; 参数描述: create sequence seq_name:创建序列,seq_name为序列名称 minvalue:自增最小值...maxvalue:自增最大值,缺省值为nomaxvalue,即不设置最大值;系统能产生的最大值为10的27次方。 start with:自增开始值,设置成21则从21开始自增。...increment by:自增数值,设置成1则每次递增1,负数表示递减,缺省值为1。...cache:定义缓存序列的个数,缺省值为20,nocache表示不设置缓存;使用缓存可以提高序列的性能,但数据库出错时会造成数据丢失使序列不连续。...from dual; end t_user_tr; 参数描述: t_user_tr: 随意的名字,不要重复就行 t_user: 表名 user_id :自增的id 删除触发器: DROP TRIGGER
缺点:获取的不是真正的自增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得知,原来,mysql主键自增有个参数innodb_autoinc_lock_mode,他有三种可能只0,1,2,mysql5.1之后加入的,默认值是1,之前的版本可以看做都是0。...id是7 delete from t1 where id in (2,3,4); -- 此时数据表只剩1,5,6了,自增id还是7 insert into t1 values(2, 106,... "test1"),(NULL, 107, "test2"),(3, 108, "test2"); -- 这里的自增id是多少呢? ...上面的例子执行完之后表的下一个自增id是10,你理解对了吗,因为最后一条执行的是一个Mixed-mode inserts语句,innoDB会分析语句,然后分配三个id,此时下一个id就是10了,但分配的三个...删除表的自增主键 删除自增主键,让唯一索引来做主键,这样子基本不用做什么变动,只要确定目前的自增主键没有实际的用处即可,这样的话,插入删除的时候可能会影响效率,但对于查询多的情况来说,小A比较两种之后更愿意选择后者
面试官:咱们聊聊mysql的自增id。...mysql自增id给我们的自增主键定义带来了很大的方便,但是经常mysql的自增id会有不连续情况,能说说什么场景下mysql的id会产生不连续吗我:我以一张表为例来解释一下,我先创建一张表zh_person...我:执行insert into table select这种语句的时候,也会出现自增id不连续的情况,因为mysql申请批量id的策略是对于同一条sql中的申请id,第一次分配一个,如果第一次分配后这个...面试官:存储在内存中,那mysql 服务重启了怎么记录自增id呢?...我:每次mysql重启都都会查找当前表的最大id值,然后加1存储到内存中作为当前id值 面试官:对这种自增id不连续的情况,对生产有什么影响吗?你有什么好的建议?
自增的值并不是保存在表结构信息内的,对于不同的版本它们有如下的区别: 1.1.1 MySQL 8.0版本之前(重启后可能会产生变化): 计数器的值存储在内存中的,重启后丢弃,下一次将读取最大的一个自增ID...该模式下可以保证同一条 insert 语句中新插入的自增ID都是连续的,但如果前一个事务 rollback 丢弃了一部分 ID 的话也会存在后续 ID 出现间隔的情况。...且当 Binlog 模式为 statement(SBR)时自增 ID 不能保证数据的正确性 1.5 自增 ID 一定就是连续吗?...不一定,业务也不应该过分依赖 MySQL 自增 ID 的连续性,在以下三种情况下,并不能保证自增 ID 的连续性: 1.5.1 插入时的其他唯一索引冲突 假设已存在数据{1,张三},且张三所属的字段设置了唯一主键...1.5.3 发生 Bulk Inserts(大量插入)时 发生大量插入时可能会出现自增ID并不是连续的情况 二、自增 ID 用完了该怎么办?
问题 对于MySQL表,如果自增ID不是主键时,是否可以用来做增量查询? 2. ...背景 需要按照自增ID字段进行增量查询,有些表的自增ID是主键,而有些表的自增只是普通索引,有些采用MyISAM,有些采用InnoDB。...// 按自增ID有序(自增ID为主键) MySQL [test]> SELECT * FROM tableA1; +----+----+----+----+ | id | af | bf | cf |...ID有序(自增ID为主键) MySQL [test]> SELECT * FROM tableA1 WHERE id>=1 LIMIT 10; +----+----+----+----+ | id | ...ID为主键时,自增ID乱序插入,查询结果也是按自增ID有序(实测有序插入一样有序),因此可以放心依自增ID增量查询,而不必指定“ORDER BY f_id”。
在一些中小型项目开发中,我们通常会使用自增 ID 来作为主键的生成策略,但随着时间的推移,数据库的信息也会越来越多,尤其是使用自增 ID 作为日志表的主键生成策略时,可能很快就会遇到 ID 被用完的情况...,那么如果发生了这种情况,MySQL 又会怎样执行呢?...PS:当然,在分库分表的场景中,我们通常会使用雪花算法来替代自增 ID,但中小型项目开发中,使用自增 ID 的场景还是比较多的。...1.自增ID 在 MySQL 中,如果字段的数据类型为整数类型(如 INT、BIGINT 等),则可以通过关键字“AUTO_INCREMENT”来设置让当前的字段实现自增,例如以下 SQL: CREATE...存在安全性问题,比如通过自增 ID 可能会推测出一些业务信息。例如,一个电商订单表使用自增 ID 作为主键,可能会被竞争对手通过订单号大致推测出业务量等信息。2.自增ID用完会怎样?
连续性 插入成功时,其数据的 ID 和前一次插入成功时数据的 ID 相邻。 自增主键的单调性 为何会有单调性的问题? 这主要跟自增主键最大值的获取方式,以及存放位置有关系。...从 MySQL 8.0 开始,自增主键最大值会在每次修改后写入到 redo log,并且在每个检查点写入引擎私有的系统表。 如果是正常重启,则读取系统表里的值。...会因为回滚而使得全局 ID 不连续。...其他 如果主动指定 ID 为 0 或者 NULL 插入,则会使用数据库生成的自增 ID。...参考文档 为什么 MySQL 的自增主键不单调也不连续 https://database.51cto.com/art/202004/614923.htm 《MySQL技术内幕——InnoDB存储引擎》
而该语句真正执行时,因唯一键冲突,所以id=2这行插入失败,但却没有将自增值改回去。 此后再成功插入新数据,拿到自增id就是3了 如你所见,自增主键不连续了!...所以唯一键冲突是导致自增主键id不连续的一大原因。 事务回滚是二大原因。 为何现唯一键冲突或回滚时,MySQL不把自增值回退? 这么设计是为了提升性能。...之所以走进如此的怪圈,就因为“允许自增id回退”这个前提的存在。 所以InnoDB放弃这样的设计,语句即使执行失败了,也不回退自增id! 所以自增id只保证是递增的,但不保证是连续的!...因为原库session2的insert语句,生成的id不连续。这个不连续的id,用statement格式的binlog来串行执行,是执行不出来的。...这是主键自增id不连续的三大原因。
领取专属 10元无门槛券
手把手带您无忧上云