这篇文章给大家聊聊关于数据库int类型长度，以及数据库int类型长度对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
知道了问题在哪，但是这个问题处理起来很麻烦，因为数据量太大了，先请教一下deepseek吧。
juejin.cn/post/…
设置BIGINT
UNSIGNED 无符号位，不算负数，可以增加一倍数据，NOT NULL 非空 AUTO_INCREMENT自增
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天多一点的时间~
1、数据量确实很大，有5E多数据，然后并发也很高。其实当初他们设计的时候也预料过这个问题，所以设了个int长度50，但是这个长度没起作用- -所以设计数据库的时候一定要做好，不然几亿数据改个字段类型要2天
还有一个小插曲，因为系统两天没消费数据，kafka的数据堆积了很多，然后我把消费者数量从30个改成50个，跑了两天，kafka还是有1天的延迟，看来麻木添加消费者数量已经没啥提升的作用了，想起八股文说多线程弄太多反而增加上下文切换的时间浪费，跟这个同理。
最后我弄成sql批量消费，消费速度马上提上去了。程序的消费策略：
单线程批量500个开始消费 ——> 30个线程单个消费 ——> 30个线程批量50个开始消费
所以说多线程异步+批量操作的策略还是很重要的！不过多线程一定要注意异步问题~
关于数据库int类型长度到此分享完毕，希望能帮助到您。
