万能的tidb社区，请问如何手动调整或分布 TiDB 集群中的 Region，目前有一台服务器tikv负载非常高，怀疑有热点问题。
热点问题就是tidb bug引起，按正常这种分布式数据库，代码就应该在建表时自动打散region.
而不应该通过人为的在创建表时候添加打散SHARD_ROW_ID_BITS = 4参数，开发人员不知道存在这样的问题，没有添加参数，然后就引起热点性能问题，最主要的是成千个表，不可能一个一个表都这么干，开发人员都是有工具创建表，工具根本就没有SHARD_ROW_ID_BITS = 4参数。
首先需要确定是热点问题造成的。
正常情况下，新版本有一定的自动调节region的能力。
如果需要手动打散，可以先通过Dashboard热力图或其它方式确定热点表，考虑使用split打散观察。
Split Region 使用文档 | TiDB 社区版
Dashboard热力图看不懂，简单就是天书，完全不知道什么叫亮和不亮，感觉只要有光都是亮的。
既然有热点，难道就不能在监控里写上某些表存在热点吗？这才叫人性化监控，而不是让我们看图去猜是哪几个表。
比如说下面这个图，谁看得出来是哪里存在热点呢？
可以查询热点表：information_schema.tidb_hot_regions
或者pdctl看看hot region
原来如此
这不是 TiDB 的 bug，是 “默认行为 + 主键 / 行 ID 单调递增” 导致的设计取舍；TiDB 确实做不到开箱即用全自动打散，必须在建表 / 表结构层面配合，或事后批量补救。
Grafana上的热点图一般要更直观一点，一般Fastune的第一张图就能看出热点了
鼠标放上去有表啊
另外SHARD_ROW_ID_BITS未必有用，从你的图上也没看出来明显热点
分布式数据库做不到完全无脑自动打散，必须配合表结构设计。
需要结合自己的业务类型决定
Raft 机制下写操作需要多数派确认，网络延迟会直接影响写入延迟。如果集群跨机房部署，建议确认下 Raft 的选举超时和心跳间隔配置是否合理。另外 PD 的调度策略默认是 balance-leader，可以根据业务读写比例调整。
都是tidb认为的热点。 TIDB_HOT_REGIONS_HISTORY | TiDB 社区版
但是看你的热力图，应该没有很持续的热点。
1、看看Dashboard top sql里 kv节点的sql对比；
2、结合Grafana上kv的指标看看qps等是否和其他节点有明显异常；
3、也有可能是该节点硬件有问题，性能变差了。
原因有很多。
TiDB 不是 “bug”，默认确实不会自动打散所有表：
只有聚簇索引主键（PRIMARY KEY CLUSTERED）且主键本身离散时，写入才天然打散。
非聚簇表 / 无主键表，会走隐式 _tidb_rowid，默认单调递增，新表只有 1 个 Region，写入全打到一个 TiKV，必然热点TiDB。
SHARD_ROW_ID_BITS 就是用来把这个 _tidb_rowid 随机打散成 2^N 个分片，避免单 Region 热点。
成千上万个表，不可能一个个改？
可以批量 ALTER + 批量 SPLIT + 加速 PD 调度，不用人肉一张张点。
同时可以全局默认参数 + 建表模板，让新表默认就带打散能力，开发工具不用感知。
可以调整 split-size 或 region-split-size 等参数来控制分裂 Region 的大小
性能问题建议先看 TiDB Dashboard 的 Top SQL 和慢查询，定位瓶颈在哪一层。常见原因有：热点 Region 没有打散、执行计划不准（analyze table）、或者 TiKV 的 RocksDB 参数没调。
手动迁移 Region 可用 pd-ctl transfer-hot-peer/transfer-peer 指令转移热点分片至空闲 TiKV。
单 Region 写入热点是 Range 分片 + 有序主键的机制问题，不是 PD 调度 bug，单纯迁移 Region 只能临时救急
如果当前集群已经出现了严重的热点,要手动 调整与打散 Region
