【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
整个库都采用tidb的自增ID, 但个别写入频繁的表，自增ID增加的特别快，2000万数据，但自增ID已经到了40多亿。其他表自增ID是正常的。用的是默认配置，这种情况怎么解决。
我知道6.4版本自增ID有升级，是全局唯一ID自增，但这需要时间验证，根据我的观察ID数据，基本上是，默认30000个ID，只用了1-2000个就直接跳到下面30000个ID了
描述问题时候，请按照：
【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【问题现象及影响】
【复现路径】做过哪些操作出现的问题
【资源配置】
描述，尽可能提供更多有效的背景信息，很多问题在不同的场景、业务下，大家可能提供的建议是不一样的，没有讲清楚只会让大家想帮忙都无从下手~
不要空着，把该填的部分填满阿…
自增ID 有好几种呢，你用的哪种呢？
auto increment，现在的问题是，部分写入量大的表会有这种问题，其他表的自增ID没有问题
auto random 呢？
对应表的AUTO_ID_CACHE 设置一下，修改为100
ALTER TABLE t AUTO_ID_CACHE 100;
如果在批量插入的 INSERT 语句中所需连续 ID 长度超过 AUTO_ID_CACHE 的长度时，TiDB 会适当调大缓存以便能够保证该语句的正常插入。
这种方式我考虑过了，但不确定把这个缓存调小会不会影响性能？
正常不会影响性能，如果有疑虑，可以先调整为10000测试一下，没问题再调小一点。
嗯，回头我试试，谢谢。
cache 分配的间隔只需要考虑到业务并发带来的量就好了
6.X 之后做了很大的优化
不过，热点问题也有可能发生
自增字段如果使用的是bigint类型（也推荐使用bigint），有符号最大值可以打到9223372万亿，无符号最大可以达到 18446744万亿，应该是足够使用的。
请求大于id生成的速度了
已经改成bigint了，之前int类型的部分已经溢出了