为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】： v4.0.7
- 【问题描述】：
我发现我们慢查询，基本都是涉及到union all的SQL。从几秒到20多秒不等。数据源表的表的数据量不大，请问如何优化？
还有个问题，就是即使是有union all的SQL，大部分情况下都是快的，偶尔会很慢，大于20秒左右，请问这个可能是什么原因？就是偶尔会卡一下
慢查询01.txt (2.6 KB)
1、给一下 tikv-detail 的监控：
导出监控方式：
打开 TiKV-Details/Overview 面板，监控时间选举最近 3 小时
打开 Grafana 监控面板（先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成）
https://metricstool.pingcap.com/ 1 使用工具导出 Grafana 数据为快照
好的
tidb-test-TiKV-Details_2020-11-24T12_58_31.347Z.zip (925.1 KB)
慢查询SQL：
慢查询01.txt (2.6 KB) 慢查询2.sql (2.8 KB)
同时我们truncate有时也特别慢
1、慢 SQL 需要你看执行计划，看慢在什么地方，另外慢日志中详述了每个步骤的耗时，看是否需要添加合适索引之类
2、truncate 慢参考：【SOP 系列 03】在线表结构变更（Online DDL）
好的。
我后来执行了很多次，这个SQL平时运行起来很快，就几毫秒。但是偶尔就会执行得慢。SQL数据源表的数据基本不变。
我的很多SQL都是，大部分时间都很快，偶尔几次就要十几秒，20多秒
1、最简单的办法是：查看慢日志，里面有一个带 plan 的字段，可以 select 这个字段，查看当时的执行计划，和现在的执行对比一下，就知道哪里变慢了
慢查询
id task estRows operator info actRows execution info memory disk
Limit_7 root 1 offset:0, count:1 0 time:16.583130781s, loops:1 N/A N/A
└─TableReader_12 root 1 data:Limit_11 0 time:16.583127169s, loops:1, cop_task: {num: 1, max:16.582888563s, proc_keys: 0, rpc_num: 2, rpc_time: 16.58253868s, copr_cache_hit_ratio: 0.00} 169 Bytes N/A
└─Limit_11 cop[tikv] 1 offset:0, count:1 0 time:0s, loops:1 N/A N/A
└─TableScan_10 cop[tikv] 1 table:t, keep order:false, stats:pseudo 0 time:0s, loops:1 N/A N/A
正常的查询
id task estRows operator info actRows execution info memory disk
Limit_7 root 1 offset:0, count:1 0 time:5.860935ms, loops:1 N/A N/A
└─TableReader_12 root 1 data:Limit_11 0 time:5.857102ms, loops:1, cop_task: {num: 1, max:5.820298ms, proc_keys: 0, rpc_num: 2, rpc_time: 5.373654ms, copr_cache_hit_ratio: 0.00} 169 Bytes N/A
└─Limit_11 cop[tikv] 1 offset:0, count:1 0 time:0s, loops:1 N/A N/A
└─TableScan_10 cop[tikv] 1 table:t, keep order:false, stats:pseudo 0 time:0s, loops:1 N/A N/A
SQL:
SELECT
t.*
FROM
fine_report.t_user_online_realtime_temp AS t
LIMIT
?
我看执行计划，除了时间之外都一模一样，能帮忙看下嘛
1、看了一下你的监控，你的资源使用很不均衡（CPU/IO），有的甚至达到了 100%
2、目前看集群其实存在很大的问题，目前怀疑是 盘和 CPU 已经严重影响使用了，建议先打散热点，具体办法：可官网搜 热点及 split 关键字
好的，我们TiDB目前数据刚部署上去，里面的数据非常少。集群资源不均衡，我觉得可能是其他服务造成的。
还想请教个问题，就是我看慢查询的执行计划里面，rpc_time:特别长，是不是由于网络连接的原因造成的？这个rpc_time是指的什么时间
给的监控目前没有网络相关的监控，所以没看，RPC 可以简单的理解为：发生在 tikv 侧的所有时间，这里包括网络时间、等待时间、各阶段的实际处理时间，目前看等待时间较长，所以怀疑是资源导致，建议还是先处理 热点问题，CPU/IO 目前使用太高了。
1 个赞
好的，谢谢
1、网络问题，我们监控中 node—exporter、blackbox——exporter 中也有相关指标，由于你目前 QPS 很少，而且看流量不算多，就没看，但也不排除其他进程占用情况，可以看看上面的指标，也可以在 overview 中的监控面板的 system info 中看 网卡流量
好的，谢谢。
可以，按你们情况决定，不过上面的问题，还是建议解决一下
1、采用 如下文档中的 第 19个 API 找到 DDL owner 属于那个节点，然后在节点执行一下 DDL 命令，看看速度如何 https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md
2、检查 tidb-server 与 tikv-server、其他 tidb-server之间的网络状况，ping 一下（在 监控 blackbox—exporter 中查看）
3、查看 tidb-server 日志。
4、查看当前集群的系统资源使用情况如何：在 监控 overview 下的 system info 中查看
好的，谢谢
有问题记得反馈
1 个赞