【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.9
【复现路径】我的表有一个时间列 MicroSeoncds 列，表示时间；目前希望某个时间段的都数据尽量分布在一个region 或者连续的region 之中。想问下，能不能通过再建一个列 Id列 自增列，让 (MicroSeconds, Id) 列组成pimary key, 这样子是不是可以让时间连续的数据分布在一个或者几个“相邻”的region之中呢？
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
这样做目的是什么？
目的是，有很多对 小范围 MicroSeconds 的查询（每次查询 的microseconds范围不重复），这样子在每次sql index look up 时，就可以将不同范围的microseconds查询，每次回表压力可以只在少数的region之上；在大并发小SQL查询场景下，就可以避免 单个region 可能存在的回表region热点?(不知道这样理解是否准确）
热点的解决方式是打散数据 
没必要，服务器内存够大其实都是访问的内存缓存而不是扫描硬盘，如果你想小范围时间的数据在一起，你用MicroSeconds或者MicroSeconds,id作为主键就行
你这不是人为制造热点么。建议好好看看文档。
完全错误，你前面说回表压力只在少数region上，不就是说这些少数region就是被集中读取的吗？这就是热点啊。怎么后面还能避免这些region成为回表热点呢？
你把你自己说的，再理解一下？
我的场景是 每次SQL的 microseconds 的范围不重叠，这种场景在大量SQL时，索引回表时发现某些region 有热点。
1 个赞
我的表没有主键，有 tidb 自动生成的 _tidb_id 作为默认主键。 micorseconds列有索引，那个这种场景下不同范围不重叠 micorseconds 可能索引回表时，导致某些region 热点？
这些region是索引热点还是表热点？
我怀疑是索引热点。
因为索引的数据少，存储的region可能更集中。再每次都要读取索引的情况下，存储索引的特定几个region容易形成热点。
表的话，时间范围都不一样，为啥会集中读取几个region。这有点怪。
不支持的
https://asktug.com/t/topic/1035262，可以参考这个case, 分析下来，初步结论是回表热点。 microseconds 不会集中在某段时间的，各段时间 的数据量基本相同。
1 个赞
看上去cpu确实不均匀，可问题是热点的region仍然不知道是那个。要找到热点的region里面是什么数据，才能知道是表热点还是索引热点。
建议你看看这个文章。
这个里面也写到cpu利用率不均匀，但这是热点的一种佐证，如果不能定位到底热点在那个region上是不好对症下药的。