analyze profile发现 ScheduleTime 耗时占比较高

【详述】SQL执行耗时要10秒左右,一共不到5亿数据,使用analyze分析,发现ScheduleTime耗时最高占据90%,多次执行SQL发现,ScheduleTime耗时要占据50%左右,平均耗时要接近4秒
【背景】先往StarRocks集群中写数据,发现执行太慢,然后停止了写,再执行SQL,发现执行还是较慢,且ScheduleTime耗时占比高
【业务影响】
【StarRocks版本】3.1.2-4f3a2ee91b
【集群规模】1fe(1 follower)+3be(fe与be混部)
【机器信息】FE配置 2C 4G,BE 配置 16C 64G,SSD盘
【联系方式】hongweijin1993@gmail.com
【附件】

使用tablet工具发现,tablet标准差比较大

测试发现一个比较奇怪的现象,查询的时候,去除where中的时间过滤(其实这个时间也包含了表中所有数据),运行更快,加上where耗时接近15秒,去除之后,8秒以内

(其实这个时间也包含了表中所有数据)
加上这个条件那会更慢的。

为啥呢?我感觉加上去,就算慢也不至于慢了这么多呀

优化器不知道您的条件是扫描全表数据的,他是按照where扫描去生成。这个跟没有where条件的执行计划不一样。

我的表是按照where那个时间来做的天分区,按照我的理解,那不管怎么整这个应该都直接下推下去了,和没有where应该相差不大来着。
我目前比较疑惑的就是为啥我去掉where过滤,ScheduleTime会增加这么多呢

我也对比了一下执行计划,只有一块有区别来着,真正执行的时候,优化器怎么优化执行的这个我还真不清楚逻辑,可能要分析一下profile

是要分析profile

目前分析下来就是 AggComputeTime 比较耗时,但是原因不太知道怎么排查了

no having group by limit 200 是可以触发一个特殊优化的。没有where的话我们构建hash表就不需要全量构建hash表了,只需要构建一个200大小的hash表。

https://docs.starrocks.io/zh-cn/latest/using_starrocks/sorted_aggregate 可以考虑修改schema用下其他的优化

或者建个物化视图,3.1 这个schedule time 不准,暂时没有参考意义

好的,不过我是主键模型,我想直接创建rollup索引是不行的

好的,我看看,感谢

你好,请问 3.3.2版本,这个ScheduleTime准吗?我现在又遇上这么个问题来着