真大佬。好了，执行时间从30s到0.01s了。

这个操作已经在执行了，看起来还有一个问题，Dashboard上看SQL的其他部分耗时几乎为0，就是这个coprocessor执行时间过长，这个有啥优化方案吗？

analyze table xxx 一手？？是这个意思吗

谢谢。

我发现过了一段时间之后，show config可以查看到状态了。不确定检测到pd元信息变更，是否需要一点生效时间？

问题已经解决，通过强制scale-in --force解决。感谢。

节点宕机了，连接不上了，这种情况，也需要先缩容吗？缩绒的时候肯定提示SSH不通啊。

[image]

现在是prune之后，没用，还是在，但是tidb的dashboard上已经没有了。

正常来说，我机器宕机了，而且使用ctl工具驱逐了节点，在prune一手，应该就完事儿了吧？

老机器无法重启，而且已经登陆不上了。报错如下： [image] 使用–force之后有如下提醒，这个不要紧吧？ [image]

执行了，好像没啥用。

ok，谢谢。

成功了。在老师们的帮助下成功了。说是region损坏导致的，这边官方老师给了一个修复脚本。修复了下就好了。

好的，谢谢您。我先加几个看看。

从经验上看，pd性能不足，再加pd能解决吗？

总服务器资源不变的情况下，增加tikv数量，也有用吗？ 就比如总数据3T，分成5个600G的store 和 10个300G的store，后者会更加好？？？

现在这个咋整啊，看着怪难受的。虽然业务访问暂时没啥报错。