【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.2.4
【遇到的问题】
早上收到服务器内存使用告警，查询占用服务，在内存占用过高过程中业务sql基本都是慢查询，发送 SQL 语句执行结果给客户端的耗时都很高，检查之间网络通讯正常，这是什么原因
查询结果集有多大？
1 个赞
是物理机部署吗？网络检查了哪些方面？ 那时间段的tidb cpu利用率多高？ 出现的慢SQL中有没有执行计划发生变化的
1 个赞
执行计划那有一个sql结果集大小，看看结果集多大
1 个赞
5万多行要四分钟。。。。
结果集看这个计划差不多要6万行了，要是 表结构varchar （255），text 等这类的话，传输就多，消耗带宽高，会有一些时间的。可以发下你的表结构，还有select 后面都有哪些字段。
网络工程师，可以 排查下应用端到数据端，之间的带宽
1 个赞
执行计划根本没耗时啊！发送结果集耗时长，要不问问业务或者看看中间件状态？
1 个赞
网络稳定么？ 有木有丢包
看看接收数据的客户端内存，cpu 等信息，是不是高了。
对端接收处理的慢，时间也会拉长
1 个赞
把overview/tidb/tikv-detail/over-view/black exporter/node exporter 再内存增长前半小时和增长期间监控导出下
导出监控步骤：
打开监控面板，选择监控时间，一定要展开所有面板，等数据加载完
打开 Grafana 监控面板（先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成）
https://metricstool.pingcap.com/ 使用工具导出 Grafana 数据为快照
1 个赞
SELECT
a.thread_id,
sql_text,
c.event_name,
(c.timer_end - c.timer_start) / 1000000000 AS ‘duration (ms)’
FROM
performance_schema.events_statements_history_long a
JOIN performance_schema.threads b ON a.thread_id = b.thread_id
JOIN performance_schema.events_stages_history_long c ON c.thread_id = b.thread_id
AND c.event_id BETWEEN a.event_id
AND a.end_event_id
WHERE
b.processlist_id = connection_id()
AND a.event_name = ‘statement/sql/select’
ORDER BY
a.thread_id,
c.event_id;
慢sql
看语句在数据库层面执行很快，发送结果耗时高主要来自两个方面原因：
1、网络耗时太长，这种情况主要是数据量大，数据库交互次数多，常见于用cursor fetch且fetchsize过小情况，这种情况每次网络交互只发生一个fetchsize记录数的请求，如果网络延迟过高那么整体耗时高。但是你这点数据量几乎不太可能。
2、应用程序处理缓慢，在用Cursor fetch(cursor fetch=yes,fetchsize > 0，优点：可以同时处理多个语句的结果集，缺点：网络次数交互太多，性能较差)的情况下，应用程序处理完本批记录（fetchsize）再向数据库请求，在应用程序处理这些记录的过程中数据库会堵塞，导致发送结果耗时比较高。如果用了流式 (fetchsize <= 0，优点：网络交互次数较少，不需要客户端多次请求，jdbc内存占用少的折中，缺点：不能并发执行SQL，需等待上一个SQL结果集处理完毕后再处理下一个SQL)和默认配置（cursor fetch=no，优点：网络交互次数很少，缺点：jdbc内存占用较大缓存所有结果集)的情况，一般不会发生堵塞。
因此排查顺序是：
1、如果jdbc驱动开启cursor fetch=yes,fetchsize > 0，那么大概率是程序问题（严重怀疑是这个问题）。
2、如果jdbc驱动开启流式 fetchsize <=0，那么有一定概率是网络原因，同时也要排查是否程序处理慢。
3、如果jdbc驱动默认配置 cursor fetch=no，大概率是网络原因。
另外，数据库内存高，主要是前端应用程序（或网络传输）消费慢，SQL查询需要再tidb-server端的tikvclient缓存tikv请求的distSQL数据。
2 个赞
可以看下dashboard监控面板中各节点的cpu和内存使用情况，以及缓存是否开启或者命中缓存。如果cpu和内存占用不高的情况下，查看是否发生了数据热点问题