关于热点问题的解决-SHARD_ROW_ID_BITS

请参考https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#%E4%BD%BF%E7%94%A8-shard_row_id_bits-%E5%A4%84%E7%90%86%E7%83%AD%E7%82%B9%E8%A1%A8和https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#%E4%BD%BF%E7%94%A8-auto_random-%E5%A4%84%E7%90%86%E8%87%AA%E5%A2%9E%E4%B8%BB%E9%94%AE%E7%83%AD%E7%82%B9%E8%A1%A8

AUTO_RANDOM本身就是打散的

谢谢 各位 如果 打散后依然出现热点 怎么解决呢

使用AUTO_RANDOM依然出现了热点吗

我是说假设,如果再出现,继续打散?如果继续打散,如何打散,因为目前有个业务考虑腰用TIDB替代MYSQL,有些情况我得提前考虑进去

AUTO_RANDOM本身就是随机的,如果这样都能产生热点,那系统压力应该相当大了,考虑加节点吧

好的,看来也只能这样了,起码知道在一种情况发生后,该如何做 谢谢

还有一种可能是比如大量请求频繁查询一个小表这种单一 Region 形成的热点,可以手动拆分region或者考虑用6.0的缓存表特性去优化。

感谢 手动拆分region能否给个文档链接 学习一下

对了,假如在热力图上显示有一个索引成为热点,该如何做,索引是非聚簇索引 ,比如

tidb官方文档中有专门关于热点问题处理的章节,如果这些方法都不能解决你的问题的话,那可以考虑选择其他技术了,比如redise。
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-热点问题处理

看下pd-ctl的用法吧


https://docs.pingcap.com/zh/tidb/stable/pd-control

hash分区

用了 AUTO_RANDOM,通过主键读写表已经打散了,不会出现热点。但是如果表中创建了二级索引,若并发量较高,二级索引可能会形成热点。可以继续对索引进行打散。

打散索引

如果在日期字段(日期精确到天或者小时)上创建索引,这样的二级索引是不是在并发量大的时候,就会容易造成热点。

索引热点通常出现在同一时刻向单调递增字段插入数据,或者同一时刻插入大量重复值的场景。这里的索引热点指单调递增字段或重复值字段上的索引。

根据索引的 KV 映射原理,可知:

  1. 非聚簇表的主键或唯一索引中的索引 Key 结构为:表ID_索引ID_索引列值。当单调递增字段同一时刻,批量插入数据时,索引 Key 必然也是连续的,会同时写入一个 Region 中,从而形成写热点。因此,若您批量插入数据时的日期字段为now()这种自动获取的值,则会产生热点。

  2. 普通二级索引的 Key 结构为:表ID_索引ID_索引列值_表的 RowID。若同一时刻,插入大量重复值时,也会产生写热点。

auto_random就不能保证有序性,这个要注意下

auto_random就是随机:grinning:

谢谢!!