执行delete后查询慢

【 TiDB 使用环境】测试环境
【 TiDB 版本】v5.4.0
【遇到的问题】
执行delete操作后,查询很慢,花费2分钟,执行delete后tiflash如何删除数据?
【复现路径】做过哪些操作出现的问题
1、一张表:query_slow_test,200w条数据,启用表同步到tiflash存储
2、同步完成,查询很快,SELECT ds from query_slow_test group by ds ;
3、执行delete数据操作,DELETE FROM query_slow_test where ds <= ‘2022-05-30’
4、delete执行快1分钟完成后,执行同样查询,花费2分钟。SELECT ds from query_slow_test group by ds ;
【问题现象及影响】
1、删除计划

	id                   	task     	estRows  	operator info                                                  	actRows	execution info                                                                                                                                                                                                                                                                                                             	memory  	disk
	Delete_4             	root     	0        	N/A                                                            	0      	time:13.2s, loops:1, commit_txn: {prewrite:18.9s, get_commit_ts:219.4µs, commit:284.2ms, region_num:3, write_keys:2691534, write_byte:51139146}                                                                                                                                                                           	48.9 MB 	N/A
	└─TableReader_8      	root     	930116.25	data:Selection_7                                               	2691534	time:1.45s, loops:2634, cop_task: {num: 3, max: 1.75s, min: 1.42s, avg: 1.58s, p95: 1.75s, max_proc_keys: 1102421, p95_proc_keys: 1102421, tot_proc: 4.12s, rpc_num: 3, rpc_time: 4.74s, copr_cache_hit_ratio: 0.00}                                                                                                       	296.1 MB	N/A
	  └─Selection_7      	cop[tikv]	930116.25	le(test.query_slow_test.ds, 2022-05-30 00:00:00.000000)	2691534	tikv_task:{proc max:1.18s, min:976ms, p80:1.18s, p95:1.18s, iters:2688, tasks:3}, scan_detail: {total_process_keys: 2738745, total_process_keys_size: 279492445, total_keys: 2738748, rocksdb: {delete_skipped_count: 0, key_skipped_count: 2738745, block: {cache_hit_count: 1935, read_count: 2867, read_byte: 20.3 MB}}}	N/A     	N/A
	    └─TableFullScan_6	cop[tikv]	2798745  	table:query_slow_test, keep order:false                        	2738745	tikv_task:{proc max:1.14s, min:952ms, p80:1.14s, p95:1.14s, iters:2688, tasks:3}                                                                                                                                                                                                                                           	N/A     	N/A

2、查询计划

	id                            	task        	estRows	operator info                                                                                                             	actRows	execution info                                                                              	memory	disk
	TableReader_31                	root        	48     	data:ExchangeSender_30                                                                                                    	1      	time:1m58.4s, loops:2, cop_task: {num: 1, max: 0s, proc_keys: 0, copr_cache_hit_ratio: 0.00}	N/A   	N/A
	└─ExchangeSender_30           	cop[tiflash]	48     	ExchangeType: PassThrough                                                                                                 	1      	tiflash_task:{time:1m58.4s, loops:1, threads:20}                                            	N/A   	N/A
	  └─Projection_26             	cop[tiflash]	48     	test.query_slow_test.ds                                                                                           	1      	tiflash_task:{time:1m58.4s, loops:1, threads:20}                                            	N/A   	N/A
	    └─HashAgg_27              	cop[tiflash]	48     	group by:test.query_slow_test.ds, funcs:firstrow(test.query_slow_test.ds)->test.query_slow_test.ds	1      	tiflash_task:{time:1m58.4s, loops:1, threads:1}                                             	N/A   	N/A
	      └─ExchangeReceiver_29   	cop[tiflash]	48     	                                                                                                                          	1      	tiflash_task:{time:1m58.4s, loops:1, threads:20}                                            	N/A   	N/A
	        └─ExchangeSender_28   	cop[tiflash]	48     	ExchangeType: HashPartition, Hash Cols: [name: test.query_slow_test.ds, collate: N/A]                             	1      	tiflash_task:{time:1m58.4s, loops:1, threads:6}                                             	N/A   	N/A
	          └─HashAgg_9         	cop[tiflash]	48     	group by:test.query_slow_test.ds,                                                                                 	1      	tiflash_task:{time:1m58.4s, loops:1, threads:1}                                             	N/A   	N/A
	            └─TableFullScan_25	cop[tiflash]	2738745	table:query_slow_test, keep order:false                                                                                   	47211  	tiflash_task:{time:1m58.4s, loops:4, threads:6}                                             	N/A   	N/A

3、慢查询时间


【附件】 相关日志及监控(https://metricstool.pingcap.com/)


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

是和这个有关?没加limit,一次删大量数据,有其他方法可以快速查询?


注意到删除后,执行计划还是 273w ,可以看下表的健康度,analaze table 下。
可以参考下相关文档:https://docs.pingcap.com/zh/tidb/stable/sql-statement-analyze-table#analyze

还有一个问题就是,group by 最好加相关索引,提高查询性能,不要走全表扫描

重新获取一下这个表的统计信息,然后把执行计划发一下。
你这个走索引比较快, 下推给TIKV。

看看GC有没有自动做过

你这个delete几乎是删除全表数据,慢也正常。删除以后留下很多碎片。影响性能。

看下dashboard里delete数据后的select 慢SQL的详细信息

这个怎么看?gc我看默认不是10分钟自己做吗

我也觉得奇怪 , 执行完删除计划 , 为啥273W, 再等几分钟看下是不是还是273万

等GC 执行后,会好很多的,删除大量的数据,实际上就是打了个标,GC 未执行的话,查询还是会扫描到这些数据的,但是会跳过,这样会影响性能了

就是有点奇怪,正常全表扫描也才1、2秒最多,删除后怎么慢了那么多

https://asktug.com/t/topic/212885

你自己看咯,这是血的惨痛教训~ :rofl:

扫描条数看还是删除前的,所有问问delete删除操作后,tiflash这边是怎么删除流程。或者我怎么能指定查询不走tiflash。analyze我试试,

analyze执行了10s,再查也花了1分多

再查询表实际行数几万,但是慢

tiflash的配置和目前资源使用情况怎么样

配置具体哪方面?一个节点128G内存复用的,1 pd ,1 tidb,3 tikv,1 tiflash,各自独立2T SSD

tiflash内存
image

重新验证了一下,新建一张表不启用tiflash,执行删除200w数据后,查询时间也很快

看了看,感觉和我这边遇到的问题还是有点区别,这文章介绍了删数据为什么那么慢,是会影响部分查询性能,我这边的关注点可能没在删数据时间长,只是删除后,在启动tiflash情况下竟然查询需要1分多,没启动tilfash,查询返回也不到1秒,差距太大了