alter table eventlog AUTO_INCREMENT=8565572,修改不掉

alter table eventlog AUTO_INCREMENT=8565572修改不掉。
tidb版本:4.0.7。
自增主键是 bigint类型的,发现表的自增属性太大,想修改,然后用mysql语法 修改:alter table eventlog AUTO_INCREMENT=8565572。修改了没效果。

1赞

auto_increment 不是这么改的

你要修改主键标识,还是调整 auto_increment 的长度?

参考下这个:
https://docs.pingcap.com/zh/tidb/stable/auto-increment

1赞


表的自增属性太大,导致插入的主键越来越大,实际上中间空了好大一截,我想改小

1赞

不是改主键标志,是改自增属性,比如改成9000000,下次自增值就是9000001,而不是当前的这么大的值+1

1赞

集群下,ID不连续是正常的,自增列仅保证唯一,不保证连续和递增

1赞

我不需要连续,现在的需求是改小这个属性值。主键值从8565472一下子跳到22111111111111了,中间空了太多了。我想把这个属性改成8565572

1赞

参考一下这里,

auto_increment_offset

  • 作用域:SESSION | GLOBAL
  • 默认值: 1
  • 范围: [1, 65535]
  • 控制 AUTO_INCREMENT 自增值字段的初始值。该变量常与 auto_increment_increment 一起使用。示例如下:

https://docs.pingcap.com/zh/tidb/stable/system-variables#auto_increment_offset

1赞

这个不是针对表的吧? 这个是针对 会话或者全局的?我现在是改某一个表的自增属性呀,就像mysql里的这个语法:alter table eventlog AUTO_INCREMENT=8565572

1赞

难道tidb里面没有改这个属性的功能吗?不至于吧

1赞

参考这个帖子的说明:

1赞

你的意思是,创建的时候指定了auto_increment,然后创建好之后,不是指定的auto_increment值吗?能提供可复现的语句脚本么?

1赞

那我这个怎么会缓存的值会那么大?我建表后直接给我搞成了22111199291573,想改小都改不了。。。,那后面这点空间根本不够我用啊

我建表指定的AUTO_INCREMENT=8565572,但是建表之后发现AUTO_INCREMENT的值是22111199291573。

我建表指定的AUTO_INCREMENT=8565572,但是建表之后发现AUTO_INCREMENT的值是22111199291573。但是不确定到底是不是这样。我是建表指定,然后导入数据之后去看这个属性发现是22111199291573的,

1赞

目前表数据量是多少?另外查一下 auto_increment_incrementauto_increment_offset这两个参数值

刚又测试了一下,应该建表的时候指定8565572成功了。然后导入的数据的id值本身就从8565472跳到22111111111111,倒入数据的最大id值是22111199282162。也就是说倒入的原始数据就空了8565472~22111111111111这么一大段。因为导入的数据的最大id值是22111199282162,所以表的AUTO_INCREMENT就在22111199282162基础上加上前面说的id缓存变成22111199291573了。现在的需求是:如何把AUTO_INCREMENT从22111199291573改成8565572,以利用空出来的那么大一段id值。mysql里直接一个命令搞定:alter table eventlog AUTO_INCREMENT=8565572。tidb目前能实现否?(备注:表的整体数据量是9000多万。)

不支持这种回写,只支持修改为大于目前ID。因为回写的话,早晚会出现ID重复的情况。

TiDB 的自增主键和 MySQL 存在差异, TiDB 中各个 TiDB Server 缓存了一段 ID,默认为 30000 个。在进行 alter 时,需要从已缓存的最大的 ID 段来进行分配,比如 :

server A:[1,30000]

server B: [30001,60000]

那么在 alter 操作的时候即使指定了目标 ID,原则上会从 60001 开始

单调性的保证,无法支持你想要的效果

主键的生成方式能不能考虑换一下?

换不了。目前该表id最大值是22111199291572,tidb里的bigint值跟 mysql的大小范围是一致的不? 从22111199291573开始,后面可用的id空间根据mysql的bigint算的话,好像可利用空间还是挺大的

那这个方案就行不通了,得你自己想办法了…