现在tikv 使用的是region leader 读取，一旦某一台tikv 资源紧张。此时调用接口后提交sql1到集群，对应sql去这台资源紧张的tikv查询数据，cop_task 时间执行长，然后会间接引起整个sql查询变慢。在此期间提交sql2到集群，如果也查询到这个k节点，会导致sql2也慢。该怎么避免这种呢，follower reader 感觉只是缓解并不能解决这个问题。
感觉优化SQL才是解决的办法
就很普通的sql 查询，也不复杂，索引也加了，执行计划里也都走索引了，cop_task 的平均执行时间不长，但是最大执行时间很长
执行计划发下看看
拿了里面我觉得重要的信息time:2.11s, loops:6, cop_task: {num: 54, max: 1.38s, min: 3.67ms, avg: 487.3ms, p95: 1.27s, max_proc_keys: 369833, p95_proc_keys: 315591, tot_proc: 18.2s, tot_wait: 16.8ms, rpc_num: 54, rpc_time: 26.3s。因为是线上任务脱敏麻烦，完整执行计划不太方便发出来
扩容吧。可以清理的话清理一部分数据
有没有热点，负载高的这个tikv节点，有没有混合别的服务。
这个节点与其他tikv节点配置不一样？
配置一样，这种也是少数情况发生，导致接口响应不稳定
优化一下s q l
感觉还是应该优化sql，走索引不一定代表就快，要看命中的索引区分度高不高，比如一个索引3个字段，只命中了1个字段，效率也不会太高。
还有看看表健康度怎么样，analyze table一下试试。
还有可能就是分布不均匀，数据都挤到一个节点上了。
正常数据均衡的话，不应该单台tikv资源紧张的，除非有热点，或者数据分布不均衡。先看下热点吧，也可以看下热门sql对应表数据region的分布情况