配置SHARD_ROW_ID_BITS 后，隐藏的 rowid 会直接复用自增值？

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】生产环境
【TiDB 版本】tidb 7.1.5

有一张表原本是聚簇索引，自增主键 bigint，后来因为写入热点要通过临时表，调整为非聚簇，于是如下所示
SHARD_ROW_ID_BITS = 6，自增值是 2012087623989455459，已经超过了 2*57

原本以为 BIGINT 很大，结果发现临时表在配置了 6 位分片后，虽然是空表，但是插入数据，TiDB 会报错 Failed to read auto-increment value

  1. 修改为非聚簇索引后，隐藏的 _row_id 会复用自增的 id 列的自增值？
  2. 增加SHARD_ROW_ID_BITS会因为占用自增位，导致支持的行数变少？
  3. 现在的 ID 已经很大了，但又想解决写入热点问题，还有别的办法吗？
CREATE TABLE `user_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) NOT NULL,
  `age` int(11) DEFAULT NULL,
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`name`, `create_time`) /*T![clustered_index] NONCLUSTERED */,
  KEY `idx_id` (`id`) 
) ENGINE=InnoDB AUTO_INCREMENT=2012087623989455459 /*T! SHARD_ROW_ID_BITS=6 */;
2

SHARD_ROW_ID_BITS 要切换成 auto_random 才会生效了…

建议新建一个表，把数据搬过来…

3

SHARD_ROW_ID_BITS 在非聚簇索引表上可用
如果是 auto random 随机主键也不需要SHARD_ROW_ID_BITS 来打散

他们开发现在强要求这个自增值，想了想没啥好办法 …

https://docs.pingcap.com/zh/tidb/v7.1/shard-row-id-bits/

4

SPLIT TABLE user_info BETWEEN (1) AND (9223372036854775807) REGIONS 16;

5

哦提前分配 region 是个方法，那如果是一次性百万的导入，直接预分配 128 个看着也行

SPLIT TABLE user_info BETWEEN (1) AND (9223372036854775807) REGIONS 128;

https://docs.pingcap.com/zh/tidb/v7.1/sql-statement-split-region/

6

让每个tikv上至少有一个region就好了

7

会增加管理上的复杂度，运维起来也会十分麻烦

8

AUTO_INCREMENT还是自增，SHARD_ROW_ID_BITS的作用没发挥出来

9

这个参数只是提供了多少个桶吧

10

是有这个问题，表热点的问题可以解决，但是索引热点的问题没有解决
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues/

11

随机分配桶，即使是自增值也可以打散表热点，但是索引热点解决不了

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues/

12

索引这个确实不知道有什么好的设计方案，期待分享经验