【 TiDB 使用环境】生产环境
【 TiDB 版本】 v5.1.2
查看 dashboard 的时候发现主要是Coprocessor 执行耗时=总的执行时间，手动执行了下执行时间ms级别 ，不知道为啥前后差距时间那么久
还有这个条件的选择度挺好的，查询出来只有一条数据，而且还是
order_no 的索引范围扫
查看 dashboard 的时候发现主要是Coprocessor 执行耗时=总的执行时间，手动执行了下执行时间ms级别 ，不知道为啥前后差距时间那么久
还有这个条件的选择度挺好的，查询出来只有一条数据，而且还是
order_no 的索引范围扫
看下是不是当时的 tikv 节点压力比较大，导致的慢。
想问下这个tikv节点的压力从哪里看，这张表查询的频率挺高的，
你截图中 coprocessor 就是 tikv 扫数据的时间，这个搞，可能是 tikv 压力较大导致的，你看下这个 SQL 慢的时间段，tikv 的 cpu 满没满就知道了。
SQL 慢可能只是服务器资源使用率太高了。
overview里面先看下tikv节点的cpu内存使用情况吧
看上去像是不均衡，有热点。
手动执行了下执行时间ms级别，手动执行执行计划是一样的吗 ？
可以看这个地方，你给你们的 read pool 多少个 cpu？
一般使用率不超过给的 80%
read pool 20 双实例 服务器64核CPU 20 这个值设置的也合理
配置为 20c 么？ 那你的 read pool 监控图来看是没有到瓶颈的。
对的 配置的是20 看监控的话差不多1/3 tikv 端应该是没有压力
检查下网络吧，看下 监控 ping 的延迟高不高。
查询tikv节点的压力，根据当时的时间戳查看grafana仪表盘，执行期间有没有较多的慢查询？
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。