执行计划cop_task max: 2.03s，明显大于其他的，为神马呢

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
根据唯一键查询，执行计划时间较久，花费近3s，
执行计划中有Concurrency:OFF

	id                     	task     	estRows	operator info                                                                                                                                                                                                                                                                                 	actRows	execution info                                                                                                                                                                                                                                                                                                                                                	memory 	disk
	Projection_7           	root     	1.00   	stat.table_abc.i_id, stat.table_abc.i_date, stat.table_abc.i_member_id, stat.table_abc.i_count, stat.table_abc.i_amount, stat.table_abc.ch_rank_list	1      	time:2.78s, loops:2, Concurrency:OFF                                                                                                                                                                                                                                                                                                                          	3.43 KB	N/A
	└─TopN_10              	root     	1.00   	stat.table_abc.i_id:desc, offset:0, count:1000                                                                                                                                                                                                                         	1      	time:2.78s, loops:2                                                                                                                                                                                                                                                                                                                                           	3.44 KB	N/A
	  └─IndexLookUp_28     	root     	1.00   	                                                                                                                                                                                                                                                                                              	1      	time:2.78s, loops:3, index_task: {total_time: 706.6ms, fetch_handle: 706.6ms, build: 1.02µs, wait: 2.21µs}, table_task: {total_time: 7.72s, num: 1, concurrency: 8}                                                                                                                                                                                         	11.3 KB	N/A
	    ├─IndexRangeScan_26	cop[tikv]	1.00   	table:table_abc, index:UNIQ_I_MEMBER_ID(I_MEMBER_ID, I_DATE), range:[813604959883265,813604959883265], keep order:false                                                                                                                                          	1      	time:706.5ms, loops:3, cop_task: {num: 1, max: 706.4ms, proc_keys: 1, tot_proc: 1ms, rpc_num: 1, rpc_time: 706.4ms, copr_cache_hit_ratio: 0.00}, tikv_task:{time:1ms, loops:1}, scan_detail: {total_process_keys: 1, total_keys: 2, rocksdb: {delete_skipped_count: 0, key_skipped_count: 1, block: {cache_hit_count: 11, read_count: 0, read_byte: 0 Bytes}}}	N/A    	N/A
	    └─TableRowIDScan_27	cop[tikv]	1.00   	table:table_abc, keep order:false                                                                                                                                                                                                                                      	1      	time:2.07s, loops:2, cop_task: {num: 1, max: 2.03s, proc_keys: 1, rpc_num: 1, rpc_time: 2.03s, copr_cache_hit_ratio: 0.00}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 1, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 16, read_count: 0, read_byte: 0 Bytes}}}                      	N/A    	N/A

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

rpc_time: 706.4ms
rpc_time: 2.03s

都是rpc_time花费高。

3

节点通信延迟较高呢，RPC Time的值越高，说明节点之间的通信延迟越大，可能会影响查询的响应时间和性能

1 个赞
4

索引问题、统计信息问题

5

1、Concurrency:OFF看下相关参数设置：show variables like ‘%concurrency%’;
2、看下mysql.opt_rule_blacklist有内容没。SQL加上这个hint /*+ LIMIT_TO_COP() */ 在试试
3、重新分析下表统计信息

6

我发现主要问题是

image
image1486×336 54.1 KB

某个cop_task明显超时，这种怎么解决呢

7

这个是稳定复现吗？

8

cop_task慢主要是tikv的原因，首先确定下tikv节点的负载，是否有节点明显负载较高

9

小菜鸟明显技术很高呀 一语中的

10

不稳定，问题就是不稳定，偶尔发生

11

通过执行计划能看到哪一台tikv负载比较高吗

12

发生时不是所有的SQL都有影响吧

13

看下grafana里面各个tikv节点在对应时间段的负载情况，偶尔发生的话，也可能是热点问题

15

热点问题怎么解决呀

16

走索引不应该这么慢，先看看集群有性能问题没，比如io是否有时候很高，CPU内存情况，可以通过监控分析分析

17

我之前遇到过类似问题，其他表的全表扫描或慢查询的io导致正常走索引的查询不稳定，等待时间过长
后来问过P社大佬，7以前的版本资源还是会互相影响的，7版本做了一些资源隔离的优化