本文转载自微信公众号“后端研究院”，作者大白鸡。转载本文请联系后端研究院公众号。大家好，我是后端研究所所长大白！今天和大家聊一个有趣的话题：如果MySQL建表时主键ID是int32自增，谁也想不到业务会发展的这么快。累死了，各种报警都要炸了，作为后台老板的你是怎么处理请求的？话不多说，看我的好兄弟小黑是怎么驾驭的，开车！提桶逃跑的计划很简单，我不管怎么对付，直接提桶逃跑！OS-1：想象一下，每个人都满怀信心地加入一家公司，但等待你的是一堆狗屎代码。OS-2：这个项目的红利都被前辈吃光了，剩下的还需要人来维护。哦，是的，没人关心谁在维护它，因为没人再关心了。OS-3：我以为我要指出这个国家，但谁知道它一直在填补漏洞。唉，时隔这么久，我还在搞土木工程呢！心中百般坎坷，最终小黑决定关掉手机，下班逃跑，回家换衣服。投完简历，他决定提着水桶逃跑。画外音：小黑的做法不可取。毕竟，跳槽往往意味着从一个坑跳到另一个坑。我们还是要正视问题，努力解决。最后祝福小黑。2方案二：求救警报还在响，小黑脸色一沉，慌张万分，旁边的同事刘某见状说道：“小黑，别慌，先止损在时间，然后寻找完整的解决方案”。听着听着，大刘一出手就有老建筑师的味道。大刘知道，讲方法论是没有用的，想出解决办法才是硬道理。图中的刘说：“小黑，你看这张表的ID是从1开始的吗？建表前期有没有坑？让数据先写到前面的空白区域，缓解在线危机。请DBA将ID字段更改为bigINT。”小黑很快就明白了大刘的意思，连忙看了看，果然有100w的坑！小黑泪流满面，恨不得抱住大刘说：“恩人啊，大刘。”说什么就做什么，小黑用了10分钟完成修改并快速上线，终于缓缓拉下了警报。100w的坑够用几天，小黑的脸也没那么黑了。然后小黑找到了DBA老张，和老张说明了情况，然后开始在线修改字段类型。由于表很大，这个操作很费时间，好在这个坑还能撑一会。最后晚上6点把表字段改成了bigint。从32位到64位，不用担心用完。小黑把大刘和老张拉到肉串王面前，感谢了这两位大神。画外音：感谢身边那些每次都提出切实可行的解决方案的同事。要成为资深架构师还有很长的路要走，小黑，加油！3方案三：与爱恋恋不舍报警就像龙卷风把小黑吹得头晕目眩，小黑想到了图灵，想到了冯诺依曼，想到了马云，想到了马化腾……经过一番思想斗争，小黑小黑决定迎难而上，去做！旁边的大刘走过来说道：“小黑别慌，这是已知问题，可能是之前的人没有解释清楚，挖了这个坑。”小黑看着大刘说道：“大刘有什么好办法吗？”不需要，可以回收一波，腾出空间让新数据写入旧ID。业务影响有限，可以及时止损。”小黑明白大刘的意思了，还好前几天刚写了一个删除数据库的脚本，没想到派上用场了，小黑小黑稍微改了一下，在线上环境中恢复了100万个ID，但是这100万个ID并不是连续的，小黑想了想决定先加一个中间层把这100万个ID存储在redis中。service先读取redis获取可用的id，然后写入数据库，这样问题就得到了缓解，quickfix上线后，告警逐渐消失，小黑赶紧找到DBA老张修改id字段类型。终于晚上6点把表字段改成了bigint，从32位到64位，再也不用担心用完了，小黑带着刘老张去木屋烧烤，并感谢这两位大神。画外音：总会有成为问题的解决方案。平时讲究积累，关键时刻提供解决问题的速度。平时多流汗，战时少流泪。4小结关于这个问题，网上很多相关文章基本都是改成bigint。这个说法不能错，但也不够及时。想象一个充满32位的大表，更改字段需要多长时间？这期间新写入的数据呢？损失不能及时止损，P0事故逃不掉。除了文中的几种方案外，还有其他结合具体场景的方法：比如新建表，双读&单写新表，总之方法不止一种，结合场景&及时止损才是真正好的解决方案。就写这么多吧！
