如果不是有>1w的空region大概率不是设置问题，很有可能是有些根据时间分区的分区表。每一个分区其实对应一个物理表，有自己的table_id,如果时间没到，这个物理表就是空的，对应的region也就是空region。 你这看着空region不算多，优先考虑是不是上面这个情况。

cost值是这么算的。还有几个参数影响这个cost值。 这个cost公式里面数值设置确实不一定非常合理。这个优化不同的硬件配置也很难通用。

起码代码上看，是收到4种信号才会推出。 然后，日志里面明确写了是收到了SIGTERM这个信号。 而kill默认发送的就是这个信号。 现在不清楚到底是不是有什么脚本在kill，还是有什么其他的原因在里面。

提供一下计算方式吧。有的指标就是一直累加的，展示的时候需要前值减后值。会不会是类似的问题？ 没有细节就不清楚是哪里有问题。

可能是版本太老了，现在只能想办法升级了。 看不到这台在执行那些sql，就没有太好的办法。

你把minIdle调大点，我感觉是应用压力不够，连接池只维持了最小连接数。你应用的压力上来了，这个连接数应该能上来的。

最好是贴个连接数的监控图。

这个图看着不像是grafana的图。是谁提供的？ 为啥不去juicefs的社区问问？毕竟是juicefs在用tikv吧？

8.1是LTS版本，8.0已经是一个DMR版本了。 8.1的发布时间，上面有人发了，就在本月

有可能是gc的问题，你看看这个帖子，看看能否解决。

同样的sql，但分到这个tikv上执行的多。有可能是读取热点。 如果是要读取的数据都集中在这个tikv上，造成的负载不均衡。 参考 https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues 看看能否解决。

之前看你提过这个mvcc版本太多，不触发gc的问题。现在解决了吗？会是这个原因吗？

空region相关的问题，你可以看看这个帖子。

topsql https://docs.pingcap.com/zh/tidb/stable/top-sql 这个界面对付单台tidb负载不均衡的情况是比较有效果的。可以尝试使用。

不能复现的bug，那就只能随缘了。下次出的时候尝试一下是否有机会。

最好是能尝试一下tiflash+mpp。 根算子是hashagg的情况下，提升会很明显。

insert平均最高的也只有20ms。 优化到多少是你能接受的？

这是由于2以上版本要首先初始化源数据库可以使用如下命令初始化 ./hive/bin/schematool -dbType mysql -initSchema 会是这个原因嘛？

很好的实践 强制checkpoint操作没有。 https://docs.pingcap.com/zh/tidb/stable/br-pitr-manual#查看备份数据元信息 但是可以通过br log metadata命令，确保最近的可恢复时间点，包含之前完整的一天。不过想要精准控制按秒级划分的话，可能确实有点难。