我感觉应该是你把新增的tikv都部署在了原来tikv 的节点上，并且目录都没有调整，导致tidb判断新加的节点和原来公用同一个的 CPU、内存、磁盘、网络IO，你正常在其他服务器上新增一个节点，理论上的schedule和region的走势应该是这样的，有条件的话建议试一下。
pd-ctl config show、pd-ctl scheduler show 和 information_schema.tikv_store_status 的内容看下
你看第三张图，data和deploy的目录是变了的。但不知道1节点多tikv这样的方式行不行。加节点我知道是可以的。
你没明白我的意思，/data这个目录应该挂载的都是同一块硬盘吧，他们的总IO是固定的啊。。。你又没有进行资源划分。。。如果要在一个节点上挂载多个tikv节点，首先通过numa来绑定两个节点使用不同的cpu和内存，然后挂载不同的磁盘例如/data和/data1分别给不同的节点，这样才会产生类似两个机器分别部署的效果。
嗯。理解你说的了。但按理来说，截图中方式也应该要支持吧，就像gp的segment一样。难道不允许这样做么？如果tidb判断新加的节点是共用资源，就默认是无效的么？
tikv之间的balance会考虑很多因素，例如：
- Region 的大小和访问频率。如果 Region 过大或者过热，TiDB 会对其进行分割和调度，使其尽可能均匀地分布在所有 TiKV 节点上。
- PD 的调度策略。PD 会根据集群的负载情况，动态调整不同维度（如 leader 数量、Region 数量、存储空间等）的 balance 策略。
- TiKV 节点的状态和容量。PD 会考虑 TiKV 节点的可用性、压力、空间等因素，优先保证集群的高可用和健康。
如果tikv都放在同一台机器上，而且没做资源隔离的话，balance可能不会像你预期的那样调整。
我的业务场景是单机多tikv实例（打上了标签），pd 会自动 balance 数据，版本是 5.4.0
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。