【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.0
【复现路径】一条正常的业务sql，正常执行查询在1s以内，但是，在tidb-server连接数上来后，查询时间直接慢到了6.5s
【遇到的问题：问题现象及影响】
1.通过下面这张截图，能否说明当时tikv出现性能问题，消耗时间比较长。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
估计 Unified read pool 都已经打满了，受影响了
1 个赞
这是你的tikv忙起来了，coprecessor线程忙不过来了
不是所有 SQL 都能高并发跑的，像那种一个 SQL 扫个几百万数据的，并发就跑不上去
看看各个tikv 的Unified read pool，是否有一台tikv干活，别的tikv在围观的情况。
另外，根算子附近是sort+hashagg ,还是个聚合计算，不过是多了些表关联，其实还是可以尝试tiflash+mpp解决。
不妨考虑加一些tiflash副本，尝试一下效果会不会更好。
dashboard查下是不是有热点，看看读写流量
1 个赞
看看监控指标呢
并发上来了，查询返回慢了 正常，同一语句结构， 可以参数化，考虑使用preparestatement
是不是监控资源的情况，并发高相应变慢是正常的啊，优化或者改写逻辑
其实很正常，车道上只有一辆车自然跑得很快，车多了拥堵了，车速就慢下来了。
多跑几次是不是效果一样
并发上来tikv跑不动了，你的SQL肯定是查了太多数据，建议贴一下完整的执行计划
1 个赞
连接数上升后，可能导致并发争用资源加剧，如锁竞争、事务冲突增多、内存/CPU/网络带宽等系统资源紧张，特别是共享资源如事务协调、全局唯一时间戳分配等环节可能会成为瓶颈
是不是有热点，热点图查看一下
连接数上来，资源不够了吧
tidb server cpu和tikv的unified read pool看下，大概率kv读满了。sql执行计划看下actrows
资源紧张吧