根因分析：
- leader drop 很高，说明 raftstore 统计到该 store 的 leader 数量在变化，变化可能是 “主键自增导致的连续热点写入” 导致的，也可能是因 tikv 过忙导致心跳出现问题等等。
- region miss 相关错误，说明在 tidb 根据 Region Cache 中缓存的旧 region leader 所在 store 位置去请求，发现 Leader 已经不在。但从给出的面板上看，没看到 Region Miss 很高的情况，Region Miss 的 SQL 会自动重试。
- cpu 使用率54%，IO使用率40% 确实不算高，但可以看到 leader drop 时间点 raftstore cpu 及 async apply 几乎掉底，但负载点前后 raft store cpu 和 async apply cpu 的压力在没调参的情况下，应该已逼近极限。证明当前 tikv 存在压力
解决方法（猜测）：
- 可以看看 dashboard 这个表有没有写入热点，有的话，表主键自增能不能改？ 比如做 shard 之类的方法避开热点。
- 看 raftstore store pool size 及 async apply pool size 默认都是 2 个 vCore，出问题前后近乎打满，可以先把这两个线程池调大。
因为面板有限，从目前信息感觉 2 点 pool 打满的根因占比更大，从 leader 仅有一个 store 特别高看，感觉是连续自增主键导致的写入热点。如果上述信息尝试后无果，可以采集一份 clinic，要不一点点要面板太麻烦了。
另外，“哪个线程用来获取这个信息？能不能增大这个”
→ tidb 获取信息的线程足够用，如 maotiancai 所说的那样，现在的问题是 tikv 有压力（不能简单只从 system cpu iousage 看），tidb 再加线程也没用。