【TiDB 使用环境】生产环境
【TiDB 版本】V5.4.3
【操作系统】openEuler 22.03 LTS
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】3PD 6TIDB 12TIKV
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】执行一些复杂sql，会导致集群所有sql都变慢，例如日常毫秒级的sql会需要执行30s甚至更久
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
这些负载sql里面很多大量的全表扫？对应时间的tikv服务器的资源怎么样？
SQL走的索引扫描，tikv的服务器cpu使用率在50%-70%
tikv的服务器cpu使用率平常也这么高吗？一般cpu使用率50%-70%的话，cpu算很忙了，coprocessor操作确实会受很大影响
平常也是比较高的，但是日常的select语句是都ok的，但是执行一些大表（几个亿）的join后，这个集群就非常慢-就平常用主键select都要10s+
要优化一下了，这语句是有点过慢了
其实如果大sql是汇总类的sql的话，建议部署一个tiflash节点，把对应sql放到tiflash上跑会比较好，现在看你的tikv节点其实压力是有点大的，如果汇总类的sql压力放tiflash上，起码你的其他业务跑在tikv上是没有什么影响的。
是需要拉取明细列表的sql，只是这种是最近才出现的，之前跑这些复杂sql影响没这么大
硬件条件好的话，tiflash 单独部署下
拉取明细数据的不太适合用tiflash吧
那可能不是很适合tiflash，能把这些sql执行时间移到业务低峰期，或者错峰执行吗？
那就是复杂sql确实会导致tikv处理变慢是吗，只能考虑错峰执行这种，还有其他一些优化手段不，服务硬件扩容或者数据库参数调整啥的
有条件扩容也可以，加几个tikv节点，争取每天tikv节点的cpu使用率不要那么高，cpu使用率很高的话，所有的key扫描操作都会受影响。