简单查询耗时很慢问题

tidb版本 4.0.13

简单的索引等值查询预期应该是几毫米就能出结果,但是执行了5min

	id                       	task     	estRows	operator info                                                             	actRows	execution info                                                                                                                                                                                                                                                                                                                                                                            	memory 	disk
	Limit_9                  	root     	0      	offset:0, count:1                                                         	1      	time:4m43.3s, loops:2                                                                                                                                                                                                                                                                                                                                                                     	N/A    	N/A
	└─IndexLookUp_22         	root     	0      	                                                                          	1      	time:4m43.3s, loops:1, index_task: {total_time: 4m43.3s, fetch_handle: 587.3ms, build: 704.6µs, wait: 4m42.7s}, table_task: {total_time: 19m27.4s, num: 255, concurrency: 4}                                                                                                                                                                                                             	52.7 MB	N/A
	  ├─IndexRangeScan_18    	cop[tikv]	0      	table:t_behavior_flow, index:idx_bid(bid), range:[66,66], keep order:false	5351797	time:534.2ms, loops:4865, cop_task: {num: 6, max: 17.9s, min: 530.5ms, avg: 4.63s, p95: 17.9s, max_proc_keys: 960000, p95_proc_keys: 960000, tot_proc: 27.6s, tot_wait: 1ms, rpc_num: 6, rpc_time: 27.8s, copr_cache: disabled}, tikv_task:{proc max:662ms, min:439ms, p80:614ms, p95:662ms, iters:5253, tasks:6}, scan_detail: {total_process_keys: 5351797, total_keys: 5351803}        	N/A    	N/A
	  └─Limit_21             	cop[tikv]	0      	offset:0, count:1                                                         	1      	time:19m23.9s, loops:256, cop_task: {num: 274, max: 10.3s, min: 20.5ms, avg: 4.35s, p95: 8.9s, max_proc_keys: 20992, p95_proc_keys: 20480, tot_proc: 18m53.6s, tot_wait: 54.8s, rpc_num: 274, rpc_time: 19m51.9s, copr_cache: disabled}, tikv_task:{proc max:1.24s, min:1ms, p80:996ms, p95:1.16s, iters:6179, tasks:274}, scan_detail: {total_process_keys: 4953849, total_keys: 6338033}	N/A    	N/A
	    └─Selection_20       	cop[tikv]	0      	eq(dbwww58com_spamrw.t_behavior_flow.uid, 34354655465765674)            	1      	tikv_task:{proc max:1.24s, min:1ms, p80:996ms, p95:1.16s, iters:6179, tasks:274}                                                                                                                                                                                                                                                                                                          	N/A    	N/A
	      └─TableRowIDScan_19	cop[tikv]	0      	table:t_behavior_flow, keep order:false                                   	4953849	tikv_task:{proc max:1.24s, min:1ms, p80:995ms, p95:1.16s, iters:6179, tasks:274}                                                                                                                                                                                                                                                                                                          	N/A    	N/A

这期间tikv节点cpu基本算被打满,持续时间大概15min,15min内的慢查询记录的都是这类sql【索引等值查询】,15min后自己恢复了

cpu 满了 执行慢正常的。。。。资源吃光的话 是整体都慢。。。。
不过你这个 SQL 应该很难打满 cpu 的。QPS 很多?感觉是被影响的。

推荐 https://docs.pingcap.com/zh/tidb/stable/top-sql 升级,这种情况 top sql 可以很快定位到具体 SQL。

你现在这个版本只能去对应时间 tikv 日志中,找 slow 关键字对应的信息。然后反查 tidb.log

uid 字段没有索引吗?

1 个赞

先去管理面板查一下先关时间段30分钟以内的慢SQL吧,你说的SQL应该不会是主要因素,应该是受其他影响了。

感觉是uid没有索引,然后bid过滤的效果很差。然后扫描时间就很长。建议给uid添加索引。

你这个执行计划,uid上没有索引,走的是bid的索引回表之后再过滤uid,然后bid过滤出来的行数非常多,回表耗费太高,建议直接建个uid+bid的组合索引。

感觉应该不是这个sql打满的tikv,可能是别的sql,这个sql慢应该是果不是因,建议排查一下这期间的其他sql或资源情况。

绝对不是这个sql引起的,肯定是某一个或者极个别的SQL 扫描大量数据导致整体都慢,你去慢SQL里面找找,再去读热点里面看看 有没有相应的SQL。

看着和这个sql关系不大。

1 个赞

这个sql是被影响的