MySQL 实战 45 讲
林晓斌
网名丁奇,前腾讯云数据库负责人
224874 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
实践篇 (37讲)
特别放送 (1讲)
结课测试 (1讲)
MySQL 实战 45 讲
15
15
1.0x
00:00/00:00
登录|注册

45 | 自增id用完怎么办?

thread_id的上限
thread_id的生成方式
trx_id的bug
trx_id的增加速度
只读事务的优化
只读事务的trx_id分配
trx_id的上限
trx_id的生成方式
Xid的重启行为
Xid的上限
Xid的生成方式
row_id用完后的逻辑
自增id用完后的逻辑
总结
thread_id
Innodb trx_id
Xid
InnoDB系统自增row_id
表定义自增值id
自增id用完了,要怎么办?

该思维导图由 AI 生成,仅供参考

MySQL 里有很多自增的 id,每个自增 id 都是定义了初始值,然后不停地往上加步长。虽然自然数是没有上限的,但是在计算机里,只要定义了表示这个数的字节长度,那它就有上限。比如,无符号整型 (unsigned int) 是 4 个字节,上限就是 232-1。
既然自增 id 有上限,就有可能被用完。但是,自增 id 用完了会怎么样呢?
今天这篇文章,我们就来看看 MySQL 里面的几种自增 id,一起分析一下它们的值达到上限以后,会出现什么情况。

表定义自增值 id

说到自增 id,你第一个想到的应该就是表结构定义里的自增字段,也就是我在第 39 篇文章《自增主键为什么不是连续的?》中和你介绍过的自增主键 id。
表定义的自增值达到上限后的逻辑是:再申请下一个 id 时,得到的值保持不变。
我们可以通过下面这个语句序列验证一下:
create table t(id int unsigned auto_increment primary key) auto_increment=4294967295;
insert into t values(null);
//成功插入一行 4294967295
show create table t;
/* CREATE TABLE `t` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4294967295;
*/
insert into t values(null);
//Duplicate entry '4294967295' for key 'PRIMARY'
可以看到,第一个 insert 语句插入数据成功后,这个表的 AUTO_INCREMENT 没有改变(还是 4294967295),就导致了第二个 insert 语句又拿到相同的自增 id 值,再试图执行插入语句,报主键冲突错误。
232-1(4294967295)不是一个特别大的数,对于一个频繁插入删除数据的表来说,是可能会被用完的。因此在建表的时候你需要考察你的表是否有可能达到这个上限,如果有可能,就应该创建成 8 个字节的 bigint unsigned。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

MySQL中的自增id存在上限问题,本文从表定义自增值id、InnoDB系统自增row_id和Xid三个方面分析了自增id达到上限后可能出现的情况。在表定义自增值id方面,当自增id达到上限后,可能导致主键冲突错误。在InnoDB系统自增row_id方面,达到上限后可能导致数据覆盖。而在Xid方面,可能会出现同一个binlog里面出现相同Xid的场景。此外,文章还介绍了Innodb trx_id Xid和InnoDB的trx_id的概念,以及thread_id的逻辑。总的来说,自增id达到上限后可能导致主键冲突、数据覆盖以及Xid重复的问题。因此,在设计数据库时,需要考虑自增id的上限问题,合理选择数据类型,以避免潜在的风险。文章通过详细的例子和逻辑解释,深入浅出地阐述了这些概念和问题,对读者快速了解文章内容具有重要意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《MySQL 实战 45 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(228)

  • 最新
  • 精选
  • 克劳德
    本人服务端工程师,在学习这门课之前数据库一直是我的短板,曾听朋友说MySQL或数据库中涉及了很多方面的知识点,每一个拿出来展开讲几乎都能出一本书了,对数据库是越来越忌惮,同时也因为工作上并没有过多接触,水平便一直停留在编写简单SQL层面。 在面试中被问到数据库问题,只能无奈的说这块不太清楚,也曾在网上自学过,但网上的文章知识点比较零散,很多都是给出一些结论性的观点,由于不了解其内部原理,记忆很难深刻。 老实说,当初报这门课的时候就像买技术书籍一样,我相信大家都有这样的体会,以为买到了就等于学到了,所以有一段时间没有点开看过,以至于后面开始学的时候都是在追赶老师和大家的进度,唯一遗憾的地方就是没能跟老师及时留言互动。 这门课虽然是文字授课,但字里行间给我的感觉就是很亲切很舒服,为什么呢,因为老师可以把晦涩的知识变得通俗易懂,有时我在思考,如果让我来讲一个自己擅长的领域是否也能做到这一点,如果要做到的话需要什么样的知识储备呢。 最后真要感谢老师的这门课,让我从心里不再惧怕数据库问题,不管是工作还是面试中信心倍增,现在时不时都敢和我们DBA“切磋切磋“了,哈哈。 祝好~

    作者回复: 👍“切磋切磋“ 留言不会“过时”哈,在对应的章节下面提出相关的问题,我会持续关注评论区

    2019-02-25
    5
    176
  • 张珂
    我觉得是这样的,人的记忆是结构化的。 如果用纯文字做读书笔记,那么一段时间之后,再来看笔记,还得根据文字重建该结构。 倒不如直接看结构化的读书笔记,省去大脑再次重建的繁琐过程。 真是文不如表,表不如图,图不如动画啊。 下面是我的《MySQL实战》的PPT形式的读书笔记,如果想复习,就快速浏览PPT,就能快速重建记忆。 https://github.com/zhangkekf/reading-notes/tree/master/MySQL%E5%AE%9E%E6%88%98 目前才更新到了39小节,当然会持续更新,如果有时间会做成动画。再次感谢林老师!

    作者回复: 这也太棒了吧,👍

    2019-06-19
    27
    155
  • 夜空中最亮的星
    不知道是最后一篇,否则的话就慢些读完了; 我是一名运维,公司也没有DBA,所以MySQL库也归我收拾; 读了老师的专栏,操作起数据库来,心情更好了; 老师的课,让我有了想看完《高性能MySQL》的兴趣; 听了老师的课,开发都来问我数据库的问题了,高兴; 老师你会有返场吗?我猜会 😄 可否透漏下接下来的安排,会有续集吗?进阶吗? 不想这一别就是一生。 您的从未谋面的学生。

    作者回复: 谢谢你 “开发都来问我数据库的问题了”,当年我也是这么开始“入坑”,加油

    2019-02-25
    65
  • Continue
    跟着学了三个多月,受益匪浅,学到了很多新的知识和其中的原理!

    作者回复: 早🤝

    2019-02-25
    57
  • 第一遍到今天就结束了,感谢老师的辛勤付出。 专栏的买的多,怕这个太长没时间学别的,也怕它太短让人意犹未尽。看评论的数量和质量,就能清晰的分辨一个专栏的优劣,老师的这个无疑是佼佼者中的佼佼者。 这个专栏学起来好像看《少年包青天》一样, 提出问题——谁是问题的凶手 分析问题——寻找问题的凶手 解决问题——找出问题的凶手 总结问题——记录抓住问题凶手的始末 真是精彩绝伦,我们程序员都是问题的终结者,发现问题、解决问题、总结问题是我们的责任。老师的指导,让我们的见识和技能得到了提升,这样便能解决更多的问题创造更多的价值。 而且我觉得技术的存在也是为了解决各种问题的, 数据库——解决数据存储的问题 WAL——解决数据一致性问题 多线程——解决性能差异的问题 锁——解决多线程并发导致数据不一致的问题 索引——解决数据查询或者操作慢的问题 日志——解决数据备份、同步、恢复等问题 数据库主备——解决数据高可用的问题 数据库读写分离——解决数据库压力的问题 数据库分库分表——解决数据量大的问题 从简单到复杂,解决一个问题就会引入一些新的问题,然后再想办法解决新的问题,事情就变得越来越复杂啦!但主体没变,附加值在一直增加,并且衍生出了许多新的东西,东西一多就需要分一下类,否则很难理解。所以,数据库按公司有分类,按存储引擎特点有分类,按功能特点有分类等等。 它的核心就是存储数据,剩下的就是怎么操作舒服怎么操作快的问题啦!想必其他工具也是如此?

    作者回复: 赞总结能力

    2019-08-10
    2
    52
  • 某、人
    很遗憾没能坚持到最后,但是也很庆幸能遇到这么好的专栏。以前了解mysql都是一些零散的知识点,通过学习完专栏,不论是mysql整体架构还是基础的知识点,都有了更深的认识。以后就把老师的文档当官方文档查,出现问题先来看看专栏。 感触特别深的是,老师对于提到的每一个问题,都会严谨又认真的去回答,尽量帮助每一位同学都能有所收获。要做到这一点,是特别耗费精力的。 感谢老师的传道授业解惑,希望以后有机会能当面向老师请教问题。期待老师下一部杰作

    作者回复: 刚过完年都是很忙的, 找时间补上哈,等你的评论区留言^_^

    2019-02-26
    33
  • MrVito
    一度想放弃,一度又再拿起,看到这里如释重负,一刷刷到28讲,就停了,因为当时感觉总是没跟上,心浮气躁,二刷从第一讲又开始刷,一个月我就刷完了,而且还能看得懂,对于一个小白来说不容易,曾经留言想放弃,没想到,晓斌老师竟然留言回我叫我加油,当时老脸一红,硬着头皮,再刷一次。而后,也坚持回答问题,虽然回答不怎么样,有时候看了评论,感觉大神太多了,真的,路漫漫兮及其修远兮,我欲上下而求索。谢谢老师,以后面试MySQL的问题我都不会怎么害怕了,遇到不懂的问题我就回来看,回来刷,成长在于点滴,细水才能长流。始终养得根深,枝繁叶茂。

    作者回复: 👍 坚持不易

    2019-09-04
    21
  • 三胖
    老师,我才学了四分之一的课程,但是这门课已经更新完了,我是直接跑到最后一节技术篇来留言的!很想知道,后来者比如我在学到后面的课程时遇到问题留言,老师还会看会回复吗?(老师的课程超值!!)

    作者回复: 会看的 后台系统是按照留言时间显示的 而且我在这事情上有强迫症,一定会让“未处理问题”变成0的😆 只是说如果是其他同学评论区问过的问题,我可能就不会重复回复了

    2019-02-25
    18
  • inrtyx
    我都看了五遍了,每次都有收获。期待老师出新的作品。

    作者回复: 👍🤝

    2020-04-06
    3
    17
  • IceGeek17
    感谢老师,课程受益匪浅, 课程结束后,如果有问题,是继续在这里的评论区提问,还是会有另外一条答疑通道? 另外,在第35篇我提了几个问题,老师还没有回答,我这里再贴一下,老师看一下 问题一: 对于BKA算法的流程理解,用文中的例子,先把t1表(小表)中查询需要的字段放入join_buffer, 然后把join_buffer里的字段值批量传给t2表,先根据索引a查到id,然后得到一批主键id,再根据主键id排序,然后再根据排完序的id去主键索引查数据(这里用到MRR) 理解是否正确? 这里对于主键id排序是在哪里做的,是在join_buffer里,还是另外再开辟一块临时内存?如果在join_buffer里,那join_buffer里的每行内容是不是:t2.id + t1查询必须的字段,并且join_buffer里是根据id排序的? 问题二: 虽然MySQL官方没有支持hash join,但是之前看到文章说,MariaDB已经支持hash join,能不能后续在答疑文章中简单总结下mariaDB支持的join算法 问题三: 在实际项目中,一个比较困惑的问题,看到过这样的类似写法: select xxx from t1 join t2 on t1.id = t2.id for update (目的是获取几个表上最新的数据,并且加上锁,防止数据被更新) 这里有几个问题: 1) 像这样 join + for update,表上的加锁规则是怎么样的?是不是在需要join的两个表上根据具体的查询执行过程都加上锁? 2)像这样 join + for update 的用法是否合理?碰到这样的场景,应该怎么去做? 问题四: 看过阿里输出的开发手册里,强调 “最多不超过三表join”,实际项目中,给我感觉很难做到所有业务都不超过三表join,那这里的问题就是,有什么相关的经验方法,可以尽量降低参与join的数据表? 比如,在数据表里添加冗余字段,可以降低参与join的数据表数量,还有什么其他好的方法?

    作者回复: 就在我们评论区,提跟文章相关的内容,会继续关注。 问题一、前面的过程理解正确,MRR过程用的是read_rnd_buffer 问题二、其实我们文中最后那个过程,你把他设想成在MySQL内部执行。。 问题三、这种复杂的语句,你要把我们两部分知识点连起来看。一个原则:for update的话,执行语句过程中扫到的间隙和记录都要加锁。 当然最好是不这么做,拆成两个语句会好些。 问题四、还是我文中的建议,如果都用NLJ或BKA算法的join其实还好,所以看看explain。 降低join表数量的方法,基本上行就是冗余字段和拆成多个语句这两个方向了

    2019-02-25
    13
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部