最终发现了MySQL主键自增值“空洞”了 1.场景准备 测试场景为MySQL 8.0： 主键重复场景 唯一键重复场景 1、建表，包含主键及唯一约束 CREATE TABLE t1( id int(...在此前，现在该表的自增值是7，重启后又变成4了。...，但如果往小的修改就要看目前数据库插入的值是否会将修改后的自增值“卡”在中间，如果出现这种情况是没办法改回去的，原因显而易见，自增属性与主键配套使用，如果现在表里id=4和id=6之间差了个5的值，将自增值改回...5，当插入数据时，自增值就会插入5的值并且把自增值加1，问题就出现了，此时自增值再进行插入就违背了唯一的原则了 4.问题拓展 在生产环境中还存在很多类似的问题，如： # 目前的插入值为8，自增值为9 mysql...可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。
自增主键最大值怎么取的？存放到哪里？...MySQL 5.7 及之前的版本，自增主键最大值会在启动(重启)后从数据库中取出放到内存： SELECT MAX(ai_col) FROM table_name FOR UPDATE; 这样获取是通过计算的...从 MySQL 8.0 开始，自增主键最大值会在每次修改后写入到 redo log，并且在每个检查点写入引擎私有的系统表。 如果是正常重启，则读取系统表里的值。...注：如果 redo log 都没刷入，就更不用说将数据插入数据表了。 自增主键插入时的连续性 这里不考虑由于删除导致的连续性问题 为何会有连续性问题？ 这主要是跟插入事务回滚有关系。...参考文档 为什么 MySQL 的自增主键不单调也不连续 https://database.51cto.com/art/202004/614923.htm 《MySQL技术内幕——InnoDB存储引擎》
自增主键：特指在自增列上定义的主键。 自增主键的优点是让主键索引保持递增顺序的插入，避免页分裂，索引更加紧凑。 1. 自增值保存在哪？ 不同的存储引擎保存自增值的策略不一样； a....对于MyISAM引擎，自增值保存在数据文件中； b. Innodb引擎，mysql5.7之前，自增值保存在内存中，而且不会持久化自增值。...每次重启后第一次打开表，都会去查找自增值的最大值max(id), 并设置表当前自增值为max(id) + 1; mysql8.0, 自增值变更记录在了redo log中，重启时依靠redo log恢复重启之前的值...自增值修改发生在插入数据的操作之前，如果插入失败，自增值不会再修改回去； b. 事务回滚也不会将自增值修改回去； c. 为了减少自增id锁带来的性能影响，mysql不会修改回去之前的自增值； 4....而对于批量插入数据的语句(select … insert，replace … select 和 load data 语句)，MySQL 有一个批量申请自增 id 的策略(注：该策略是导致自增 id 不连续的第三种原因
mysql自增主键设置 在数据库应用中，经常希望在每次插入新纪录时，系统自动生成字段的主键值。可以通过为表主键添加AUTO_INCREMENT关键字来实现。...默认情况下，在MYSQL中AUTO_INCREMENT的初始值是1，每新增一条记录，字段值自动加1.一个表只能有一个字段属用AUTO_INCREMENT约束，且该字段必须为主键的一部分。...AUTO_INCREMENT约束的字段可以是任何整数类型(TINTINT、SMALLINT、INT、BIGINT等) 设置表的属性值自动增加的语法规则如下: 字段名 数据类型 AUTO_INCREMENT...创建表，指定编号自动递增 create table tb_emp8( id int(11) PRIMARY KEY auto_increment, name VARCHAR(25) not null...FLOAT ); 执行插入语句： insert into tb_emp8(name,salary) values('lucy',1000),('lura',1200),('kevin',1500); 查看数据表
mysql自增值保存的位置 在我们使用mysql时，会遇到自增主键。那么不同的引擎有着不一样的自增值保存策略，对于自增值保存的位置，我们分为两种情形讨论。...1、MyISAM引擎的自增值存储在数据文件中。 2、InnoDB引擎的自增值，在MySQL5.7和之前的版本中，自增值保存在内存中，不会持久。...每一次重新启动，第一次打开表格时，都会找到自增值max(id)，然后把max(id)+步长作为当前的自增值。...select max(ai_col) from table_name for update; 在MySQL较高版本中，自增值的变化记录在redolog中，重启时依靠redolog恢复重启前的值。...以上就是mysql自增值保存位置的介绍，希望对大家有所帮助。更多mysql学习指路：MySQL 推荐操作系统：windows7系统、mysql5.8、DELL G3电脑
——埃伯克 今天重置mysql自增主键时遇到个坑，明明sql执行了 ALTER TABLE table_name AUTO_INCREMENT= 1; 但还是修改失败了 后来发现原来是因为当前表最大...id比我设置的自增id大导致的 而且这种情况还不报错，提示sql正常执行，就挺坑的 最后把表内数据调整了，成功重置自增id 可以通过 SHOW TABLE STATUS WHERE NAME = 'user
环境说明： MySQL 5.7 、MySQL 8.0 长期以来，我的博客数据库中连续文章的主键编号一直都不是连续的，让我这个强迫症晚期患看着很不舒服。...把改完主键编号的文章数据导入新数据库之后，就产生了一个新问题：现在新数据表的主键自增值还是旧数据表的主键自增值。...查看自增值 一般来说，数据表中具有自增属性 AUTO_INCREMENT 的字段主要是数据表的主键或者具有唯一性的字段。...FROM [数据库名] 表示指定查询所在的数据库；LIKE [表名] 指定该数据库下要查询的某个表，如果省略了 LIKE [表名] 子句，则表示查看该数据库下的所有表的信息。...比如查询 TEST 数据库下 test 表的信息： SHOW TABLE STATUS FROM TEST LIKE 'test'; 查询结果中有一个字段名为 “AUTO_INCREMENT”，表示的就是自增值
不同的引擎对于自增值的保存策略不同 1.MyISAM引擎的自增值保存在数据文件中 2.InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保存在内存里，并没有持久化。...每次重启后，第一次打开表的时候，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当前的自增值 select max(ai_col) from table_name for update...假设，某次要插入的值是X，当前的自增值是Y 1.如果X<Y，那么这个表的自增值不变 2.如果X>=Y，就需要把当前自增值修改为新的自增值 新的自增值生成算法是：从auto_increment_offset...（初始值）开始，以auto_increment_increment（步长）为步长，持续叠加，直到找到第一个大于X的值，作为新的自增值 三、自增值的修改时机 创建一个表t，其中id是自增主键字段、c是唯一索引...出现了自增主键不连续的情况 唯一键冲突和事务回滚都会导致自增主键id不连续的情况 四、自增锁的优化 自增id锁并不是一个事务锁，而是每次申请完就马上释放，以便允许别的事务再申请 但在MySQL5.0版本的时候
平时我们使用MySQL时，通常每一个表都会有一个自增主键ID，每新增一条数据，ID值就会自增1。但在8.0之前版本的MySQL中，这个自增值会存在一个回溯的问题。...例如，在一个新表中插入三条主键为1、2、3的数据行，这时候用SHOW CREATE TABLE命令查看该表的AUTO_INCREMENT的值是4，这是没问题的。...然后把ID=3的数据行删掉，再次查询AUTO_INCREMENT的值，依然是4，这也是没问题的。 但如果重启一下MySQL，这个值就会变回3，而不是4，发生了回溯。...这是因为AUTO_INCREMENT的值只存储于内存中，不会持久化到磁盘，每次启动数据库时，MySQL会通过计算max(auto_increment字段) + 1，重新作为该表下一次的主键ID的自增值。...这个问题直至MySQL 8.0才修复。 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/149188.html原文链接：https://javaforall.cn
这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15.../16），则开辟一个新的页（节点） 4、自增主键 如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页 5、非自增主键 如果使用非自增主键...总结 如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高： 1、使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的...，和B+数叶子节点分裂顺序一致； 2、该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候InnoDB会选择内置的ROWID作为主键，写入顺序和ROWID增长顺序一致； 除此以外...《高性能MySQL》中的原话 ? ?
很多小伙伴应该知道，在 MySQL 中主键不应该使用随机字符串。但是主键不用随机字符串用什么？主键自增？主键自增就是最佳方案吗？有没有其他坑？今天我们就来讨论下这个话题。 1....为什么不用 UUID 经过上篇文章的介绍，我们知道在 MySQL 中，主键索引就是聚簇索引，MySQL 表中的数据是根据主键值聚集在一起的，聚簇索引是一棵 B+Tree，这棵树中的数据是有序的。...基于上面的分析，我们在 MySQL 中尽量不使用 UUID 作为主键，不用 UUID，可能会有小伙伴想到，那我使用主键自增行不行？...主键自增有没有一些需要注意的问题？ 2. 主键自增的问题 以下内容，有一个共同的大前提，就是我们的表设置了主键自增。 一般来说，主键自增是没有什么问题的。但是，如果在高并发环境下，就会有问题了。...SQL 语句开始的时候，获取到一个表级的 AUTO-INC 锁，然后当插入 SQL 执行完毕之后，再释放掉这把锁，这样做的好处是可以确保在批量插入的时候，自增主键是连续的。
下面这个脚本是采集数据库自增主键水位的（遇到过业务主键设置过小，导致出问题的，因此我们必须将自增id的水位线监控起来） IP_ADDR=$(/sbin/ip a|egrep '10.[0|1].[1-9...]+.[1-9]+*' | awk '{print $2}'| cut -d '/' -f 1); mysql -uroot -p123456 2>/dev/null -e "set @ip='$IP_ADDR... WHERE c.extra = 'auto_increment' AND t.TABLE_SCHEMA NOT IN ('information_schema','mysql...', 'sys','test','performance_schema') AND t.auto_increment IS NOT NULL ; " 关于MySQL的采集脚本， 在prometheus...的mysql_exporter的源代码里面，有很多，大家感兴趣的可以自己去看一下代码。
SELECT a.id id, a.gmt_create gmtCreate, a.gmt_modified gmtModified, a.app_id app...
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内...
1、数据库表结构如下: create table student( id int(11) primary key not null auto_increment comment '学号', name varchar...auto_increment, name varchar(100), supervisor_name varchar(100), leader_id int(11) comment '班长学号' ); 2、测试数据 class表...student表 3、问题描述: 问题：查询数学成绩最高的学生信息和该学生班长的姓名 想法：想要获取班长的学号必须将学生表和班级表做一次内连接，但这样只能拿到学号，拿不到班长的姓名，所以用班长的学号再和学生表做一次自连接即可
自增主键可以让主键索引尽量的保持递增顺序插入，避免页分裂，索引更加紧凑。 自增主键保存在何处？...不同的引擎对于自增值的保存策略不同： MyISAM引擎的自增值保存在数据文件中 InnoDB引擎的自增值保存在内存里，但是在MySQL8.0以后，该自增值才可以被持久化：MySQL5.7以前，自增值没有持久化每次重启后第一次打开表的时候...，会找自增值的最大值max(id)，然后将最大值加1作为这个表的自增值；MySQL8.0版本会将自增值的变更记录在redo log中，重启时依靠redo log恢复。...自增值的变更情况如下，假设某次要插入的值是X，当前的自增值是Y： 如果X<Y，表的自增值不变 如果X>=Y，需要把当前自增值修改为新的自增值 新的自增值生成算法 从auto_increment_offset...values(null, 1, 1); 执行器调用InnoDB引擎写入一行，传入的这一行的值是(0,1,1) InnoDB发现用户没有指定id，获取表t当前的自增值2 将传入的行改为(2,1,1) 将表的自增值改为
你也可能经常会看到一些关于 mysql 军规、mysql 查询优化的文章，其实这些操作的背后都是基于一定的原理的，你要想明白这些原理，首先就得知道 mysql 底层的一些东西。...我们都知道表的主键一般都要使用自增 id，不建议使用业务 id ，是因为使用自增 id 可以避免页分裂。这个其实可以相当于一个结论，你都可以直接记住这个结论就可以了。...我这里也稍微解释一下页分裂，mysql （注意本文讲的 mysql 默认为InnoDB 引擎）底层数据结构是 B+ 树，所谓的索引其实就是一颗 B+ 树，一个表有多少个索引就会有多少颗 B+ 树，mysql...如果主键为自增 id 的话，mysql 在写满一个数据页的时候，直接申请另一个新数据页接着写就可以了。...如果主键是非自增 id，为了确保索引有序，mysql 就需要将每次插入的数据都放到合适的位置上。
MySQL 主键 自增 ID 会用完吗？...首先我们一般创建 MySQL 数据表的时候，大部分情况下会创建一个自增主键ID 的字段，可能你的建表语句如下： CREATE TABLE IF NOT EXISTS `tb`( `id` INT...所以 在 MySQL 中 自增 ID 是会用完的。那么问题来了，加入他的 ID 用完会发生什么事呢？ 我们来验证下。...如果会那么久需要创建 8 字节的 INT 类型了，他的值最大是 2^64-1 那么问题又来了，你说 我有些业务是不需要主键 、不需要自增编号，我不创建这个字段，就好了，这样想恭喜你 回答错误....总结： 自增 ID 用完 会报主键冲突、数据插入失败。 不指定主键、默认创建的 row_id 会 覆盖原有的数据。
全文摘要 结合实例分析了自增值保存在哪里，自增值的修改策略，以及自增值不连续的四个场景，希望对各位小伙伴们有所帮助~ 众所周知，自增主键可以让聚集索引尽量地保持递增顺序插入，避免了随机查询，从而提高了查询效率...但实际上，MySQL 的自增主键并不能保证一定是连续递增的。...以上，是在我本地 MySQL 5.x 版本的实验，实际上，到了 MySQL 8.0 版本后，自增值的变更记录被放在了 redo log 中，提供了自增值持久化的能力，也就是实现了“如果发生重启，表的自增值可以根据...理解了 MySQL 自增值到底保存在哪里以后，我们再来看看自增值的修改机制，并以此引出第一种自增值不连续的场景。...如下图所示，自增值仍然固执地从 4 增加到了 5： 所以这时候我们再去插入一条数据（null, 3, 3）的时候，主键 id 就会被自动赋为 5 了： 那么，为什么在出现唯一键冲突或者回滚的时候，MySQL
1.一个没加主键的表,它的数据无序的放置在磁盘存储器上，一行一行的排列的很整齐. 2.一个加了主键的表,并不能被称之为「表」。...如果给表上了主键,那么表在磁盘上的存储结构就由整齐排列的结构转变成了树状结构,并且是「平衡树」结构,换句话说,就是整个表就变成了一个索引。...这就是为什么一个表只能有一个主键,一个表只能有一个「聚集索引」,因为主键的作用就是把「表」的数据格式转换成「索引（平衡树）」的格式放置。 ....有一种例外可以不使用聚集索引就能查询出所需要的数据,这种非主流的方法称之为「覆盖索引」查询,也就是平时所说的复合索引或者多字段索引查询 以上内容希望帮助到大家，很多PHPer在进阶的时候总会遇到一些问题和瓶颈...不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
