【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1
【复现路径】触发页面A，A页面会调用很多的接口，其中很多的接口都会调用触发B-SQL，只是B-SQL的where条件不一样。
【遇到的问题：问题现象及影响】
在dashbroad面板上的慢SQL监控，监控到该B-SQL，发现执行时间为20s左右。于是将B-SQL复制出来单独执行，只需要花费4s左右。
查看了系统负载，cpu和内存最高使用率也在80%内。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
把 SQL 完整贴出来
并发sql就是比单sql执行慢啊，你单sql执行的时候，是不是在业务高峰期测试的
对比下执行计划，看看执行计划的路径是否完全一致，如果有变动，所以还有优化空间的
然后 B-SQL 对应的查询数据是否有很大的变动，如果没做健康度的更新，采集的统计样本数据也会引发执行计划路径的变化，会不准…
建议按照以上的角度，逐个排查
1 个赞
cpu真到80%负载很高了
资源上边是不是有啥瓶颈，CPU，网卡，线程池
执行20s和4s的执行计划有嘛？
一个是查询数据是否存在倾斜，一个是两个测试时间点负载是否一样？
会不会存在性能瓶颈
把sql的explain analyze执行计划贴出来看下吧，纯猜没啥意义。。。
执行计划发一下，sql 发一下，grafana 和 dashboard 的截图发一下
并发时会比单独慢的。这是常见地。反过来就少见。。。
一个SQL在并发执行查询的时候耗时比单独执行时间长？这个是正常的呀
CPU不能到80%，这太高了
没有具体的信息啊，太宽泛了。
explain analyze执行计划能发出来不？况且，20s和4s的执行条件和环境也不一样啊
看一下s q l的执行计划呢
我这边也出现过，其实有点怀疑是tikv 内部的并发 或者排队机制有待完善
B-SQL的where条件不一样，那就要分析下这些不同where条件SQL 是否都执行很快
性能截图发一下