查询2亿数据group by 报Out Of Memory Quota

🪐 TiDB 技术问题 性能调优
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
V5.0.1

【问题描述】
在查询 ```
SELECT id FROM test.temp_wyy_container GROUP BY id HAVING count(1) > 1 LIMIT 10;

时，执行计划为
	id                        	task     	estRows  	operator info                                                                                                                                 	actRows 	execution info                                                                                                                                                                                                                                                                                                                                                                          	memory    	disk
	Limit_12                  	root     	10       	offset:0, count:10                                                                                                                            	0       	time:38.7s, loops:1                                                                                                                                                                                                                                                                                                                                                                     	N/A       	N/A
	└─Selection_13            	root     	10       	gt(Column#57, 1)                                                                                                                              	0       	time:38.7s, loops:1                                                                                                                                                                                                                                                                                                                                                                     	1000 Bytes	N/A
	  └─HashAgg_18            	root     	10       	group by:test.temp_wyy_container.id, funcs:count(Column#59)->Column#57, funcs:firstrow(test.temp_wyy_container.id)->test.temp_wyy_container.id	0       	time:38.7s, loops:1, partial_worker:{wall_time:53.27934705s, concurrency:5, task_num:407, tot_wait:1.772206924s, tot_exec:3m25.024801148s, tot_time:4m15.596407043s, max:53.279316613s, p95:53.279316613s}, final_worker:{wall_time:38.715596459s, concurrency:5, task_num:0, tot_wait:3m13.577827339s, tot_exec:3.3µs, tot_time:3m13.577840414s, max:38.715578703s, p95:38.715578703s}	12.8 GB   	N/A
	    └─TableReader_19      	root     	10       	data:HashAgg_14                                                                                                                               	69376399	time:619.3ms, loops:411, cop_task: {num: 410, max: 1.22s, min: 151.5ms, avg: 514.4ms, p95: 735.8ms, max_proc_keys: 236991, p95_proc_keys: 216028, tot_proc: 3m12.4s, tot_wait: 219ms, rpc_num: 410, rpc_time: 3m30.9s, copr_cache_hit_ratio: 0.00}                                                                                                                                      	131.9 MB  	N/A
	      └─HashAgg_14        	cop[tikv]	10       	group by:test.temp_wyy_container.id, funcs:count(1)->Column#59                                                                                	69376399	tikv_task:{proc max:766ms, min:128ms, p80:527ms, p95:589ms, iters:67978, tasks:410}, scan_detail: {total_process_keys: 69380215, total_keys: 101652704, rocksdb: {delete_skipped_count: 0, key_skipped_count: 171380169, block: {cache_hit_count: 142210, read_count: 479878, read_byte: 6.13 GB}}}                                                                                     	N/A       	N/A
	        └─TableFullScan_17	cop[tikv]	218397758	table:temp_wyy_container, keep order:false                                                                                                    	69380215	tikv_task:{proc max:521ms, min:78ms, p80:390ms, p95:434ms, iters:67978, tasks:410}, scan_detail: {total_process_keys: 0, total_keys: 0, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 0, read_count: 0, read_byte: 0 Bytes}}}                                                                                                                       	N/A       	N/A

报的这个问题。我把 `mem-quota-query`参数从1G修改成10G还是报。请问如何从内存优化的角度来处理这个问题？？？



---
若提问为**性能优化、故障排查**类问题，请下载<a href="/uploads/short-url/uGisshjxFnxx1KgpFOYbfeZjsc6" download="info_gathering.py">脚本</a>运行。终端输出的打印结果，请**务必全选**并复制粘贴上传。
2

表结构发一下，这个id 列看起来没有索引？

3

是的没有索引。我把索引加上再试试。另外问下我从INFORMATION_SCHEMA.TABLES表中算的占用表空间的值是算上副本的，还是没有算副本？？

4

但是像我这种SQL就是扫描全表的，索引是否能优化？

5

建议先反馈下表结构，需要先看看id的属性

6

OK了。我加了索引很快就出来了。感谢。还有一个问题。SELECT TABLE_NAME,(DATA_LENGTH+INDEX_LENGTH)/1024/1024/1024,TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA=‘test’ AND TABLE_NAME=‘temp_wyy_container’; 这个SQL查出来的表空间占用，是不是包含了3副本的量？？

7

这个是单副本的数据量，这个是理论值哈。