TIDB切换server节点之后，导致 auto_increment 自增表ID发生变化，当前ID小于最大ID的问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.3

业务库的ID是 auto_increment自增的，当前显示的Max(id)是 544679，然后show create table显示的 AUTO_INCREMENT是570001

 CREATE TABLE `groupMessageTask` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 ... ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=570001 COMMENT='群发消息任务表' |

然后按时间倒序排列当前的最新ID是 500433;
TIDB官方提示 “自增编号是系统批量分配给每台 TiDB 服务器的值（默认 3 万个值）”

现在的问题是，
1、如何确认分配给server就是默认的30000个ID范围呢？
2、如何查询指定server节点这个ID范围具体是多少到多少呢？

1 个赞
2

不用搞的太麻烦，直接AUTO_ID_CACHE=1，这样换tidb 节点也是递增的。

3

嗯，新的业务表可以这样搞，但是目前是从MySQL迁移过来的老表，中间因为各种问题切换过不同的Server节点，现在发现当前的自增ID是小于Max最大值的，不确定会不会到时候这个范围用光，发生住建冲突的问题

5

那这个id应该和原来的mysql表保持一致吧？
我听你的意思是这块已经不一致了？成了mysql和tidb各自算自己的递增id了？

如果说已经不一致了，那我觉得反而好处理了，重设一下这个表的自增id，大到不冲突就好了。反正也没有办法和原来的mysql做数据溯源了。

更好的办法还是从上游重新导入一遍，如果是从mysql迁移的，当初没考虑到溯源，随着时间推移查同步错误的难度会越来越大。可能同步错了也很难看出来。

6

SELECT * FROM INFORMATION_SCHEMA.TIDB_TABLE_INFO WHERE TABLE_NAME = ‘groupMessageTask’; 表的自增ID分配信息

ALTER TABLE groupMessageTask AUTO_ID_CACHE 100; 调整每个TiDB节点缓存的ID数量