自增主键打散热点

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

【TiDB 版本】 v3.0.15

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

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

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

【问题】

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

image
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的写热点问题 》文中提及下面三种情况下的规避解决方案

成因 规避或解决方案
自增主键 不要使用自增主键,可改用 UUID 等,或使用 AUTO_RANDOM
无主键/联合主键/非 INT 类型主键 使用 SHARD_ROW_ID_BITS
INT 类型主键,且连续写入数值接近的主键 将该主键改为普通索引,再使用 SHARD_ROW_ID_BITS

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

在进行试验操作的时候发现 下面三种情况都不会使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 */


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

1赞

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

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

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

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

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

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

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

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

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

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

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

谢了:sweat_smile:,,3.0无法使用auto random亚子

:woman_technologist:t3:好的好的,谢谢