企业官网建设流程全解析

林业网站源码,福建建设厅安全员报名网站,网站建设与管理的发展,网红营销的缺点点击标题下「蓝色微信名」可快速关注 数据库的主键我们有时候会用自增列#xff0c;但是自增都会有个上限#xff0c;如果达到怎么办#xff1f;技术社群的这篇文章《MySQL自增id超过int最大值怎么办#xff1f;》就给我们讲解了MySQL数据库自增列达到上限该怎么办#xf…点击标题下「蓝色微信名」可快速关注数据库的主键我们有时候会用自增列但是自增都会有个上限如果达到怎么办技术社群的这篇文章《MySQL自增id超过int最大值怎么办》就给我们讲解了MySQL数据库自增列达到上限该怎么办借鉴学习下。一、故事背景今天运维反馈有一个设备在后台查不到我第一时间怀疑可能是数据出了问题导致服务报错了没有入库。我拿着日志去本地请求接口发现程序是没有报错的我们的逻辑是先将唯一id放到redis里面如果redis没有值就insert有就update做了一层缓存估计是这样的话批量插入和更新数据库会快一点。然后我看redis是有值的以为是redis和数据库数据不一致问题我就把redis的key删了重新再跑一下结果打印了insert语句但是没有插入到数据看来事情并没有那么简单。二、问题分析因为数据表很大有5E数据我第一反应是mysql表数据量可能爆了但是查了下好像没有太大限制再认真看了下表的自增id这个数字让人有点熟悉的这个不就是int的最大值吗。意思是因为自增id超过了int所以插入失败了id设的就是int类型还有个小彩蛋目前数据库设的int长度是50但是根本没什么鸟用。知道了问题在哪但是这个问题处理起来很麻烦因为数据量太大了先请教一下deepseek。三、方案处理deepseek给我提供了三个方案第一个是最简单粗暴的改BIGINT不用迁移数据但是会全程锁表。第二个分布式ID需要重新设计表需要把数据迁移到新表而且还要redis等支撑。第三个分库分表就更麻烦了分库分表需要引入框架不按照分片查询还需要引入ES引入了ES还需要引入同步mysql和ES的中间件logstash等。但是改bigint估计锁表太久我先看看有没有其他办法先紧急处理下数据。但是按理说int最大值是21E数据表数据才5E按理说是用不完的。结果我看到自增的id值居然是不连续的。按理说自增id应该是一个接着一个不会有空隙的后面查了一下由于数据库自增id有个高性能策略设置了id就不一定连续。后面又查了下有没有一键把数据表id重排的方法结果也是没有的。最后我是写了一个存储过程先将最后100万的id清理出来可以先顶个几天后面再想办法处理BEGIN DECLARE start_id INT DEFAULT 1; DECLARE end_id INT DEFAULT 100000; DECLARE current_batch INT DEFAULT 0; WHILE start_id end_id DO -- 更新临时表中的ID UPDATE table SET id start_id 1 WHERE id (select original_id from ( SELECT id AS original_id FROM table ORDER BY id DESC LIMIT 1) as test); SET start_id start_id 1; END WHILE;END最后重新设置自增值如果自增值已经存在则会跳到max(id)1-- 重置自增值ALTER TABLE your_table AUTO_INCREMENT max(id)1;清理了大概500万的id段出来然后我怀疑id间隔这么大是因为并发太高导致的。一开始程序是单线程消费到500条就批量入库但是后面发现单线程消费比较慢数据量太多消费有点延迟。后面改成java批量消费配置了30个消费者。接着我尝试了一下减少消费者数量设置成15个id的间隔真的变小了。四、设置BIGINT节后回来发现id还剩200万讨论到最后还是把id的数据类型从int改成bigintALTER TABLE xxx MODIFY id BIGINT UNSIGNED NOT NULL AUTO_INCREMENTUNSIGNED无符号位不算负数可以增加一倍数据NOT NULL非空 AUTO_INCREMENT自增。在测试环境有一亿数据修改id的类型大概用了一个小时现网我估计也是用6-7个小时也差不多了。结果改了一晚上都还没改好然后我找了一个可以查询sql进度的语句SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED, ROUND(WORK_COMPLETED/WORK_ESTIMATED*100, 2) AS Progress (%) FROM performance_schema.events_stages_current;跑了十几个小时居然还不到50%而且还越跑越慢。对比了一下测试环境和现网环境的buffer_pool等数据也是设置正常。估计是索引树变大插入的数据要花多不少时间还有一个就是现网数据库还有其他线程会抢占CPU导致速度缓慢。统计了一下后面的数据大概是1个小时完成1.5%左右周一晚上执行的但到周四早上上班的时候才跑完用了2天多一点。五、总结之前刷到一篇文章《字节面试MySQL自增ID用完会怎样》评论区都说有没有用完的结果我真用完了就感觉有点不可思议。总结一下有几个原因1、数据量确实很大有5E多数据然后并发也很高。其实当初他们设计的时候也预料过这个问题所以设了个int长度50但是这个长度没起作用- -所以设计数据库的时候一定要做好不然几亿数据改个字段类型要2天。2、数据库的自增id策略选了高性能策略导致并发高的时候id间隔很大。30个消费者异步处理10条数据大概用了100个id的间隔消耗太快了。所以这里存在一个时间和空间的取舍使用多线程还是挺危险的操作要谨慎一点。还有一个小插曲因为系统两天没消费数据kafka的数据堆积了很多然后我将消费者数量从30个改成50个跑了两天kafka还是有1天的延迟看来麻木添加消费者数量已经没啥提升的作用了想起八股文说多线程弄太多反而增加上下文切换的时间浪费跟这个同理。通过改造成sql批量消费消费速度马上提上去了。程序的消费策略单线程批量500个开始消费 —— 30个线程单个消费 —— 30个线程批量50个开始消费。所以说多线程异步批量操作的策略还是很重要的不过多线程一定要注意异步问题。如果您认为这篇文章有些帮助还请不吝点下文章末尾的点赞和在看或者直接转发朋友圈可以到各大平台找我微信公众号bisal的个人杂货铺腾讯云开发者社区bisal的个人杂货铺头条号bisal的个人杂货铺CSDNbisalITPubbisal墨天轮bisal51CTObisal小红书bisal抖音bisal近期更新的文章《Instagram十亿级用户名已被占用背后的架构设计》《为轮子造轮子的教训经验场景》《国子监辟雍内部匾额少了一块么》《英超第二十一轮》《冬季奥运会观赛赛程》近期Vlog《千岛湖》《Skyline Luge》《新疆之行红山体育馆 - 国际大巴扎 - 红山公园 - 天山天池》《新疆之行天马浴河 - 哈因塞 - 那拉提 - 依提根塞》《新疆之行六星街 - 伊昭公路 - 夏塔》热文鉴赏《揭开仿宋和仿宋_GB2312的神秘面纱》《Linux的aarch是多了个a》《中国队“自己的”世界杯》《你不知道的C罗-Siu庆祝动作》《大阪环球影城避坑指南和功略》《推荐一篇Oracle RAC Cache Fusion的经典论文》《红警游戏开源代码带给我们的震撼》文章分类和索引《公众号1900篇文章分类和索引》