+1， 跟 join 关系不大，主要问题在 rpc_time 上；
- rpc_time 表示 “向 TiKV 发送 Cop 类型的 RPC 请求总时间”， 在 tikv-client go 中记录 runtime 信息合并而来；
- rpc_num 表示 “同上 RPC 请求个数”；
- rocksdb: {delete_skip_count …} : 源自 protobuf，是 tikv 传过来的 → 详见定义
- tikv_task: {time …} 也是 tikv 传过来的，–> 详见定义
- 这个问题又只有 1 个 rpc_num，说明同样是一个请求，在 tikv 执行 task 的时候时快时慢；
一般这种问题有 2 种可能：
- 时间耗在 网络抖动上
- 属于长尾情况，大部分请求都在 ms 级，时不时蹦到 s 级，s 级的比例并不高，不改监控看不出来（p99,p999），但是从 rocksdb 相关信息看 tikv 回传信息对应点位 不太可能慢在 tikv 处理流程。 也就是说，慢在 grpc request end + network + grpc response end。 要么是 rust grpc 慢了（概率低），要么是 tikv grpc goroutine 慢了（概率低），要么是网络抖了。
感觉这种情况应该占比 该 SQL 总执行次数比重不大吧？
- 网络抖 看 ping latency
- 如果要细查 grpc request end 和 grpc response end 执行情况，tikv 测可以看看 tikv-details → grpc 下面的面板，可能还要改下 分位数曲线，想看极端情况，把 99 线改 1 看极端情况。
- 如果能稳定复现的话，最好 trace 一下，这个同时观察 这 1 个 region 的 request 发给哪个 tikv 了，然后沿着请求链路的面板，看看是否有蛛丝马迹。