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数量

7

首先，要明确只保证唯一，不保证递增这个基本设定。
1、show create table中的id为570001，大于最大id和最新id，满足建表后id不重复的要求。正常
2、时间倒序最新id，不等于最大id，原因是 不保证递增 的设定。正常

可以试试这个函数，获取上次递增id
https://docs.pingcap.com/zh/tidb/stable/information-functions#last_insert_id

8

last_insert_id有坑，一次插入多条返回第一条的值

9

这个last_insert_id是在当前session中手动执行了插入，再执行才会有记录的。

现在是生产环境具体表的验证，这个没有意义，通过时间排序就能知道当前的最新ID

10

这个还没有尝试过。记录下

11

:joy:额。。。那有点略坑了，还真没测试过。自从老版本知道不是递增之后，就没有使用这个功能了。

12

你这是用的那个版本，我使用7.5.3 没有 TIDB_TABLE_INFO表

13

在实际业务中，我们是用guid+时间戳取代自增id了，guid保证唯一，时间戳保证递增。不过，我们这边的业务场景，时间戳保留到毫秒，基本上也是唯一递增的了。

1 个赞
14

不是不一致，是因为在TIDB这边，切换server了，然后自增ID跳了，而且是跳到之前的范围了

比如现在是544123 ,我切换TIDB server，然后这表的自增ID变成了从 497588开始了。
如果知道 497588 所分配的区间的话，就能知道这种跳越，尤其是跳到之前小的ID会不会最终导致主键冲突了

当然手动修改表的自增ID为当前最大+1也行，但是这样以后切换server的话，都需要手动修改来保证不冲突就很麻烦嘛

1 个赞
15

嗯对，这种针对新业务直接使用TIDB，在 业务侧提前设计好的话，是挺好的方案

16

我懂了，是我的理解有问题。
我以为从mysql同步这个过程还在，看样子这个同步过程已经结束了。

17

对，同步已经解决，切割过来有段时间了，中间因为各种原因切换过server节点几次

分析了 一个表的切换点的ID跳跃，发现它可以自己找到”历史没有使用完的ID区间“继续。

比如这次的切换的 495578开始，就是历史切换之后从480001开始增长到478577结束（该结束点也是发生了一次切换跳跃到了540001）的继续。

按照这个逻辑，猜测这次的495578增长到510000之后会重新从本次的 544676之后的544677开始。

目前添加了监控来验证的猜想

18

AUTO_ID_CACHE=1肯定能保证递增啊

19

新业务可以这么设置，老的迁移过来的没有这么设置。因为涉及表太多，没有办法确认没有跳到更小的范围去

20

迁移的时候改下建表语句就行