换成我们的话，就会重建这个表，不会去fork源码。现在我们的表都是统一字符集，统一排序规则。因为在实际使用过程中，发现两个表的排序规则如果不同，会造成索引不命中的尴尬场景。

可以先按官方指引，把一次性积分都拿了。大概有1000+的积分。

首先，要明确只保证唯一，不保证递增这个基本设定。 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

检查一下配置文件中的这个配置项 raftstore.capacity

找了几个我们这边的看了一下，这里都是用root部署，显示的就是root。不知道和这里有没有关系。

tidb用户不能管理？那为什么display里显示是tidb？中间重建过tiup么？ 嗯，br是物理备份，应该是可以的。

可以考多次，考过了也能再考，支持大佬刷分

CPU怎么那么高？是混合部署么？

基本上都有在用👍

可以用br备份试试。tidb有没有应该没影响。 另外，试试用tidb用户登录，然后执行tiup 扩容试试。

这两步都验证，都没问题？那奇怪了。 [image]

用tidb登录，然后ssh ip，可以不用输入密码么？

使用tidb用户部署的？重新做遍免密互信呢。 [image]

不会也是ubunut吧

感觉就是做了优化，但不确定有没有bug，所以加了个开关，默认不开启优化，但是可以通过修改变动启用优化，以验证优化效果。 [image] 相关issues https://github.com/pingcap/tidb/issues/55153 https://github.com/pingcap/tidb/issues/53127

不会是bug没修复吧

这种方式可以。 建表时将 AUTO_ID_CACHE 设置为 1 https://docs.pingcap.com/zh/tidb/v7.5/auto-increment#mysql-兼容模式 不过也可能是不连续的。 [image]

不支持 [image]

飘红发一下吧~