那是否可以理解为有很多这种 IN 条件查询的SQL，在 unified read pool 中排队，可能需要将程序中的并发调小一点？
但这个时候集群的 qps 还是比较低的，不到 1 k.
这个图中三个机器的 Unified read pool CPU 差距很大，这个也比较奇怪，其中一台 CPU 被打满，另外两台的 CPU 基本都没怎么用到
这个 read pool cpu 3台交替增长，跟前面11:12-14分间的延迟突增、tidb/tikv CPU 突降对不上啊
这边集群还有一个信息就是，目前这个集群的网卡是千兆的，后面会找机会更换成万兆。但是看了一下那个时间段的网络负载，也没有达到瓶颈
cluster-Overview_2022-11-28T06_52_22.769Z.json (105.7 KB)
这个是 system Info 的信息
其中的 TCP Retrans 在这个时间段有点异常
diag 文件夹用 tiup diag package 打包后，上传到 pingcap clinic 网站的时候，报 It’s not a valid diag package，怀疑是不是因为 diag 版本太低了
有可能，升级看看
升级 tiup 后，现有 tidb 集群应该是不受影响的吧？
tiup不影响集群，不升级cluster 就行