为了更快的定位您的问题，请提供以下信息，谢谢
【详述】max_by/min_by 按照时间复杂度来说运行效率要比 row_number() over(partition by a,b order by c desc) 好，实际消耗内存和耗时比row_number() over() 多 。
max_by 时间复杂度O(n) row_number()over(partition by … order by … [asc|desc] 的时间复杂度为O(nLOGn),是什么原因导致的慢，是否可以优化下？ Q2：max_by(a,b) 参数b 应该支持struct 函数 实际不支持。
【背景】做过哪些操作？
【业务影响】
【是否存算分离】
【StarRocks版本】例如：current_version()|
3.3.22-ee-e7e1135|
【集群规模】例如：3fe（1 follower+2observer）+5be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【联系方式】为了在解决问题过程中能及时联系到您获取一些日志信息，请补充下您的联系方式，例如：社区群4-小李或者邮箱，谢谢
【附件】
- fe.log/beINFO/相应截图
- 慢查询：
- Profile信息
- 并行度：show variables like ‘%parallel_fragment_exec_instance_num%’;
parallel_fragment_exec_instance_num|1 | - pipeline是否开启：show variables like ‘%pipeline%’;
Variable_name |Value|
------------------------------------------±----+
enable_aggregation_pipeline_share_limit |true |
enable_pipeline_engine |true |
enable_pipeline_level_multi_partitioned_rf|false|
enable_pipeline_level_shuffle |true |
max_pipeline_dop |64 |
pipeline_dop |1 |
pipeline_profile_level |1 |
pipeline_sink_dop |0 | - be节点cpu和内存使用率截图
- 查询报错：
- query_dump，怎么获取query_dump文件
- be crash
- be.out
- 外表查询报错
- be.out和fe.warn.log
> 引用预格式化文本
-- row_number() over() 执行计划：
– max_by() 的执行计划：
详见附件explain.sql (421.3 KB)
– 资源消耗比对：row_number()
CPU Cost:12m3s955ms
Mem Cost:2.51GB
Exec duration:15s605ms ( 2026-05-11 19:28:45 ~ 2026-05-11 19:29:01 )
Scan Bytes:5.69GB
–资源消耗比对：max_by
CPU Cost: 16m58s336ms
Mem Cost:5.03GB
Exec duration:18s809ms ( 2026-05-11 19:29:01 ~ 2026-05-11 19:29:20 )
Scan Bytes:5.69GB