自增主键打散热点

[llplmlyd]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】

【TiDB 版本】 v3.0.15

【概述】 一张自增主键业务表存在热点【读/写】，导致单个tikv coprocessor 达到瓶颈，业务接口报超时

【现象】 集群上所有查询变慢

【背景】
查看了官方文档和asktug 相关文档之后进行了对应的 split table 和热点调度处理，仍存在疑问。
目前正在考虑是否进行分片处理。因为业务的表是自增主键类型的，不太清楚是否能够直接进行SHARD_ROW_ID_BITS分片，或者或分片之后是否能对热点有所改善。

【问题】

1.官方文档中提及的 更多热点问题中无提及 自增主键的解决方案

https://docs.pingcap.com/zh/tidb/v3.0/high-concurrency-best-practices#更复杂的热点问题
问题：

• 按照文章，请问是这个意思吗：反过来说 只有 没有主键的表 或者 非int类型主键表 使用 shard_row_id_bit 和pre的参数才有可能避免热点问题。其他情况，未知。
• 请问自增主键的表就不能使用 shard_row_id_bit 了吗？
• 第三个问题确认一下，第二篇文章《如何分析和解决 TiDB 4.0的写热点问题 》中的解决方法的正确性，自增主键只有这种解决方案吗？

2. 《如何分析和解决 TiDB 4.0的写热点问题 》文中提及下面三种情况下的规避解决方案

https://asktug.com/t/topic/34032
|成因|规避或解决方案|
|–|—|—|
|自增主键|不要使用自增主键，可改用 UUID 等，或使用 AUTO_RANDOM|
|无主键/联合主键/非 INT 类型主键|使用 SHARD_ROW_ID_BITS|
|INT 类型主键，且连续写入数值接近的主键|将该主键改为普通索引，再使用 SHARD_ROW_ID_BITS|

3.下文中有官方回答说“如果主键是 int 或者 bigint 类型时候 SHARD_ROW_ID_BITS 是并不生效的”？是否的确无任何作用？

SHARD_ROW_ID_BITS会影响自增id的取值范围,是否是一个BUG

应该和这个已知问题类似 https://github.com/pingcap/tidb/issues/17460 如果目前有 block 点可以通过 alter table tablename SHARD_ROW_ID_BITS=0 来绕过 本身 如果主键是 int 或者 bigint 类型时候 SHARD_ROW_ID_BITS 是并不生效的 [image]

在进行试验操作的时候发现 下面三种情况都不会使region 分裂。Leaders Distribution并没有发生改变。所以是不是自增主键表如果不改造业务，只能通过split table region手动打散热点临时解决呢？

• 创建时 指定了SHARD_ROW_ID_BITS
• 创建时 指定了 SHARD_ROW_ID_BITS 和PRE_SPLIT_REGIONS
• 写入数据之后 ALTER table table_name SHARD_ROW_ID_BITS =xx;初始化的时候会产生多个region，但是没有数据写入，很快又合并剩下一个region。

使用的表结构模型如下：
CREATE TABLE table1 (
id bigint(20) NOT NULL AUTO_INCREMENT ,
msg_id varchar(128) NOT NULL ,
origin_data mediumtext NOT NULL ,
error_msg mediumtext DEFAULT NULL ,
create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘创建时间’,
update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’,
PRIMARY KEY (id),
KEY msg_id (msg_id),
KEY create_time (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=374354/*!90000 SHARD_ROW_ID_BITS=3 */

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[xfworld (魔幻之翼)]

首先，你用的3.X的版本，就无法适用于 4.X 的文档，你可以考虑下升级，不过 3.X 和 4.X 的区别很大，升级需要做好测试

然后，热点问题，在任何单点服务系统中都会存在，你的场景是什么？想要解决什么问题呢？

[qizheng]

不改造业务的情况下，在数据库侧也可以考虑将自增主键表改成 auto_random 主键，4.0.13 版本支持将列属性 AUTO_INCREMENT 变更为 AUTO_RANDOM

[llplmlyd]

第一篇是3.0的喔，第二篇只是借鉴，所以才来这里提问，确认一下3.0版本的解决方案呢。
？？？？场景和问题里面写了呀，一张表引起的热点，目前就是针对这张表进行热点改造，确认改造方案

[llplmlyd]

如果不升级呢？现在这个版本没有办法使用auto_random属性，是不是无解了？

[qizheng]

不升级没办法在线改造，需要将数据导入新表

[llplmlyd]

不升级的话，是需要重建表结构，把主键设置成随机字符串？

[qizheng]

把主键列设置为 auto random 将其他列的数据导入新表

[xfworld (魔幻之翼)]

不升级，你可以自行改造主键策略，来满足打散数据的要求，这样也可以

你引用的东西太多了，不知道你要问什么，发帖最好能清楚的描述自己的期望

参考Action文档：
https://book.tidb.io/session4/chapter6/serial-number.html

[llplmlyd]

谢了，，3.0无法使用auto random亚子

[llplmlyd]

好的好的，谢谢

[magongyong]

请问4.0.13版本将auto_increment改为auto_random的操作步骤能否简单介绍下，我这边尝试改了下，不行呢，我发的帖子：auto_increment改为auto_random报错

[疾风之狼]

建议还是升级到高版本吧，低版本功能不太强。