tidb 偶尔执行union all 慢,如何优化?

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【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 中看 网卡流量

好的,谢谢。

我们的表都不大,可否通过开启下推运行结果到tikv,来解决热点问题?

可以,按你们情况决定,不过上面的问题,还是建议解决一下

您好,我发现我们TiDB的truncate越来越慢了。而且没有发生链接中所说的几种情况,我们现在tidb的并发,数据量等都很小,请问可以怎么解决这个问题?


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赞