情景描述：
Doris 版本是 2.x ，所有表为 Unique 模型，其中存在单表数据记录行数过亿的情况，均与以 createTs 时间类型字段按月分区。
① 7 表 join 相互关联后的某个查询操作 SQL执行会耗时约 2 秒 ( 按 createTs 的筛选时间跨度超 1 年 )，最后会命中 100 条以下的查询记录
② 与 ① 中相同 SQL 仅在最后额外使用 order by 某张表的 executionTs (该字段属于 Value 列) 时间类型字段排序，结局是 BE 爆内存，报出形如 …… process memory used 13.77 GB exceed limit 12.35 GB or sys mem available 47.01 GB less than low water mark 1.54 GB. 的异常
上述相同 SQL 语法，想通数据量，在普通 oltp 数据库也能在人能接受的时间内返回结果，
我目前知道的方案：
- ① 中 SQL 外面再嵌套一层 Select ，将本体转化为子查询，在父查询中进行
order by(这种人工改造 SQL 体验上很蠢的感觉，查询优化器不能实现成智能识别，把排序操作放在where等条件筛选后吗？) - ① 中 7 表关联操作拆解成多次查询，最终在 Doris 数据库外部的应用程序进行最终查询结果的拼装、排序 (相当于重写业务代码)
对于这种在 Doris 非 Key 列字段排序的操作，Doris 有什么更好的优化方案吗？