了解了。方便截图一下完整的 慢查询数量、查询总数量的图吗？
这段时间是还未进行任何操作时的慢查询数量，比例927/109924约等于0.84%
这是我最近10分钟的日志，开启了您说的配置，并且没有上报profile，慢查询比例851/59560约等于1.42%
不开启上报profile的话，pipeline_profile_level配置就没有意义了，所以两个时间段的区别就是
pipeline_dop = 5 以及 enable_pipeline_engine = true，除此之外没有任何区别
我看慢查询数量没有降低趋势，我把pipeline引擎再次关闭了
看起来没有之前的差距那么大了？您方便再提供一个 pipeline 慢查询的 profile 吗？pipeline_profile_level=1 就可以。
这里为了性能没有开启profile上报，如果开启上报的话就和前面发过的profile一样了
了解了。您 set global pipeline_dop = 10; 再试试看，慢查询还会明显增加吗？
现在有什么线索吗，每次测试都会导致慢查询数量大幅上升，SLO指标扛不住了 
会不会和pipeline_exec_thread_pool_thread_num配置有关，这个配置默认是cpu核数，是不是需要增加一下
pipeline_exec_thread_pool_thread_num 不需要更改。
主要是二者的并行度不一样，并行度高会创建更多的任务来执行查询，每个查询又不是很大，所以高并发时 任务越多会导致任务的调度开销越大。
- 关闭 pipeline 时的并行度
parallel_fragment_exec_instance_num只有 1。 - 开启 pipeline 时的并行度
pipeline_dop=0会设置为核数一半（20）。
因此，尝试降低 pipeline_dop，慢查询就会有所降低。但是 pipeline 和非 pipeline 的一些执行逻辑不同，所以也不能降得太低。pipeline_dop=10 应该会比 pipeline_dop=5 的慢查询更少一些。
您最后再 set global pipeline_dop=10; set global is_report_success=true; set global pipeline_profile_level=1 试试看呢？就是 pipeline_dop=10，开启 profile、但是 profile_level=1。
好的，我申请按您给的配置试一下
没找到明显变慢的profile，应该是整体都慢了一小点
看了一波源码，不开启资源组时和开启资源组时的driver_queue是不一样的，因为StarRocks2.3.2有bug导致我没办法开启资源组，打算等国庆回来升级一下StarRocks2.3.3，然后打开资源组配置，使用work group driver queue，看看是不是能够解决现有的性能问题
我怀疑目前的性能问题在于高并发场景下，pipeline worker由于第一条数据来的慢暂时放回queue后，优先级设置的不合理，导致任务没有及时的再次启动，拖慢了查询的整体时间。
QuerySharedDriverQueue
着重看了一下不开资源组时这个队列的代码
感觉问题就出在这
它将查询任务按照已经消耗时间分为了8个队列，并且在分配任务时，按照队列总消耗时间进行了加权分配，前一个队列的权重是后一个队列的1.2倍
分队阈值为0.2s, 0.6s, 1.2s, 2s, 3s, 4.2s, 5.6s, and 7.2s
在我的业务场景下，99%以上的查询在150ms以内，此时0.2s的队列总的执行时间会非常高。
此时如果来了一条慢查询，分配到了0.6s甚至更高的队列里，那么即使进行了1.2倍的加权，因为整个队列的执行时间较小，该任务的优先级也会非常高，因此导致了be倾注了所有资源到这条慢查询里面，导致查询时间短的普通查询，因为队列整体运行时间过长的原因，分配不到资源，变为慢查询。
这种猜想和我实际遇到的慢查询都是扎堆一起出现的现象很一致。
可能会有这个问题，但是可能性不是很大。Profile 中 ScheduleTime 是查询任务在就绪队列中的时间，如果因为调度优先级导致的饥饿问题，那么慢查询的 ScheduleTime 会特别长，但是实际 profile 中的 ScheduleTime 不并不是特别大。
我在曾经调试Flink任务的时候也遇到过了这种5分钟粒度慢查询突刺的情况，不过是2.0版本时期的问题了，当时遇到的一个情况是，flink任务5分钟粒度的窗口，数据也就5分钟落盘一次
即使落盘的数据总量一样，但是当我调大StarRocks Sink算子的并行度30 -> 90 时，每整5分钟就是数据落盘的那一分钟会出现大量的慢查询语句，当时没有调查清楚原因，把并行度调整的改动回退后就没再出现这种情况了。
profile (51.2 KB)
我在今天将集群版本升级到了2.3.3 开启了资源组配置。
性能还是不及预期
根据我对profile的分析，发现有些地方的数据不太合理，您能看看是什么问题吗
- Aggr: 1s75ms
- __MAX_OF_Aggr: 1s463ms
- __MIN_OF_Aggr: 820.179ms
- SegmentRead: 9.753ms
- __MAX_OF_SegmentRead: 1s87ms
- __MIN_OF_SegmentRead: 0ns
- ScanTime: 13.517ms
- __MAX_OF_ScanTime: 1s551ms
- __MIN_OF_ScanTime: 1.774us
- Union: 847.660ms
- __MAX_OF_Union: 1s165ms
- __MIN_OF_Union: 639.750ms
这几个地方的Max和Min值差距较大，也是整个profile首次出现了秒级别的时间，应该是整个sql的瓶颈所在，根据我的分析问题主要在SegmentRead/ScanTime里，由于某种原因，导致个别线程加载数据过于缓慢，影响了SQL的整体运行。
我不知道应该调整哪些参数来解决这个问题