tikv:
coprocessor.split-region-on-table: false
PD
tiup ctl:v4.0.13 pd -u xxx.xxx.xxxx.xxx:2379 -i
config set enable-cross-table-merge “true”
滚动重启pd|kv亲测有效，要等一段时间merger
我是v4.0.12版本的，这里Operator limit没有有merge-checker-merge这一项，我已经将您说的两个参数调整了，还是不见明显下降。
看下监控，上面贴的图。看下到底有没有生成merge operator。还是说生成后取消了。
这滚动重启。。。。。。不太好吧。实在不行我再试试这个方法吧。
sheduler show 看下。
就只有这4个，这里都没动过的啊，手动添加一个merger scheduler？
[
"balance-hot-region-scheduler",
"balance-leader-scheduler",
"balance-region-scheduler",
"label-scheduler"
]
好像默认就是这几个。我看到有个random-merge-scheduler 不知道干什么用的。
要么就试试重启吧
，把pd的一个follower重启，起来以后再用上面的命令把leader切到新启动的节点试试。
要么看看pd的日志，有没有什么报错。
reload配置也是滚动重启的，找个业务空闲窗口，reload下没什么影响
集群规模在 56w region 的话，1w 左右的 empty-region 应该不是什么问题。现在集群需要关注的主要是磁盘使用率不均，有部分节点使用率较高。目前来看调度是有在工作的，不过速度比较慢。提供的监控信息中 Scheduler 和 Heartbeat 这两部分有缺失，能否重新抓取一下？以及提供一下 store limit 数据，可以通过 pd-ctl config show all 或者 pd-ctl store limit 命令来获得。
pending-peer-region-count 现在也有1k多，几天前还只是有几个。
可以将 max-pending-peer-count 更改到 64 试试。另外 TiKV 这边有 pending-peer 堆积的现象的话，可以也看一下 TiKV 的监控。
empty的消失了？最终怎么触发的？ pending-peer是region迁移的时候会有一些，region迁移是先增加一个peer，再删除一个。增加的一个还没同步上就是pending。慢慢会消失的。
empty没有消失，只是楼上说empty12K+是正常现象，我们在排查其他部分了。我们也考虑是不是merge empty region时候造成的penging-peer较大，但是这两个参数似乎都是僵死状态，没有什么大的变化。
看你这个监控截图
merge check最大689k，其中有687k noneed merge（大于max-merge-keys和max-merge-size）
剩下的2k中有1k是special-peer(pending 和down peer)
340多是最近分裂的
390多是no-target
所以，可能那2k没法merge的一部分是pending的？
这个Max值不知道参考意义大不大，目前基本这个Region merge checker的各项参数都0，但是empty和pending-peer的region还是分别保持在10K和1K左右，这个现象在三天之前是没有的，我们的业务这几天也没有什么变化，唯一变化的就是有几台服务器磁盘因为不均衡所以有点满了。现在通过扩容已经稍稍改善了存储空间，但是这几个参数还是居高不下，一些写入任务也比之前延迟更大了。
看起来有很多 no-need 的 region 并且 region 数量也有在缓慢下降。需要确认 region size 以及调度参数。
1.可以 ctl pd -u pdip:port region check empty-region >empty-region.info获取一部分 region id。
2.然后 tiup ctl:v5.1.4 pd -u pdip:port region xxxx |grep approximate 确认一下这些 region 最新上报的 region size keys大小。
3. 比对一下 ctl pd config show all 中的 max-merge-keys 和 max-merge-size。
4. 再贴一份当前 pd config show all 参数贴到帖子中。