order by 查询慢

并行度是在哪里看

show variables like ‘%para%’

INSERT INTO MY_TABLE(Variable_name, Value) VALUES (‘parallel_exchange_instance_num’, ‘-1’);
INSERT INTO MY_TABLE(Variable_name, Value) VALUES (‘parallel_fragment_exec_instance_num’, ‘14’);

parallel_exchange_instance_num’, ‘-1’
‘parallel_fragment_exec_instance_num’, ‘14’

这个有数据倾斜,可以show tablet from $table看下每个tablet的数据量

Result_1.csv (71.2 KB)

这个是查询出来的结果

你有一个桶的数据量(datasize)为4017292224,其他都是几十万左右,这些差距太大了,导致这个桶的查询拉低了整体的时延。StarRocks查询scan性能分析 参考下这里数据倾斜的部分,这张表需要重新设计下,更改并选择合适的hash键,可以通过hash键分组count下,每组结果差距不大的话就是比较合理的。

老哥这些信息在哪看的,我们最近在使用starrcosk也遇到了这个问题,使用order by的时候比mysql还慢的多

获取Profile,通过Profile分析查询瓶颈 - StarRocks用户问答 / 常见 FAQ - StarRocks数据库论坛 开启profile,将慢查询的profile发一下,建议单独开个帖子

命令行执行set is_report_success = true

然后浏览器访问http:服务器ip:http端口(默认8030),然后执行慢SQL去刷新网页端能在query里找到你执行的SQL,后面profile

多谢老哥,你们现在这个order by速度上来了嘛,我们的分桶键使用的是fid,每个桶数量都挺均匀的

没有,分桶键试了好几个,找了个比较平均的,剩余的话,就是分桶数量最好是cpu核数的一半,现在我们这边准备看下不行把慢sql的字段单独建表去试试

不知道排序是不是starrcosk的劣势方面,同一条sql在mysql秒出结果 :joy:

可以尝试下分桶数量改为 BE数量*CPU核数一半再试试,刚才无意间看到的

我们一开始的分桶数就是3be*8核/2=12桶,好像没有啥用 :joy:

老哥 现在有没有解决办法

发个profile和建表看下

麻烦帮忙看看 对比了两个字段的order by ,以start_time排序比较慢,以flow_id排序就比较快。
(目前是测试环境,以start_time作为分区键,但是测试数据的时间不是很均匀导致分区之间数据多的有100多万行,少的有几十行)
orderby-flow_id.txt (29.6 KB) orderby-start_time.txt (29.3 KB) 建表语句.txt (1.3 KB)