TiKV 节点读压力飙升，tidb-server 连接数飙升，慢查询突然增加

[Hacker_1bOJKx43]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
TiDB-v3.0.9

【概述】 场景 + 问题概述

【背景】 做过哪些操作

【现象】 业务和数据库现象
8月31日9:45开始至10:05分，tikv节点告警：Tikv coprocessor request wait seconds more than 10s 。tidb-server中连接数由平时的60增加到150，且有较多查询卡住。tikv多台实例的cpu和流量激增。
【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
TiDB-v3.0.9
【应用软件及版本】

【附件】 相关日志及配置信息

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）
  
  
  
  
  
  

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[Hacker_1bOJKx43]

tikv.log (3.8 MB) tikv日志如下

[undefined]

@Hacker_1bOJKx43

equest wait seconds more than

dashboard 看下 keyviz 热点表
顺便看下 按执行时间排序 的 慢查询

[Hacker_1bOJKx43]

慢查询都是走了索引的，平时执行也比较快。 3.0.9版本没有keyviz

[这道题我不会 (Lizhengyang@PingCAP)]

从 tikv 日志中看 从 9:38 开始有大量的慢查询，建议重点排查下慢 SQL ，看下是否是 SQL 执行计划发生改变等原因导致的，可以根据慢日志中的 process_keys 进行下排序，SQL 语句类似：

select query_time, query, digest
from information_schema.slow_query
where is_internal = false  
  AND time >= '2021-08-31 09:30:00'
  AND time < '2021-08-31 10:10:00'
order by Process_keys desc
limit 10;

[Hacker_1bOJKx43]

谢谢 经过排查，发现一条慢查语句使用的索引字段出现某一个值数据量过大导致查询过慢，优化后后续我们再观察一下。