1 背景

原 Mondrian 逻辑中，所有排序操作均在内存中执行，需加载全量数据至内存，导致性能瓶颈。本次优化通过新增配置项，将部分排序逻辑下沉至 SQL 层执行，仅返回排序后的分页数据，降低内存压力并提升性能。

2 配置项说明

3 可优化场景

以下场景可通过配置项触发排序下沉，两个选项只是针对某些固定场景下的优化。

3.1 纯维度排序支持性能优化

报表上只有维度排序的场景，比如下图，只有“发货区域”：

3.2  原子度量全局排序优化

原子度量的全局升序、降序：

3.3  维度排序与原子度量全局排序组合优化

维度的全局排序、组内排序以及原子度量的全局升序或全局降序：

3.4 维度排序和原子度量组内排序组合序

当在交叉表中，如果有多个维度，当前面的维度都设置了排序，只有最后一个维度没有设置排序时，才可以优化性能； 

4 无法优化的场景

以下情况排序逻辑仍需在内存执行，无法通过配置项优化：

• 计算度量排序：计算度量需内存计算，无法下沉。
• 含度量过滤的场景：度量过滤依赖计算度量逻辑，无法下沉。
• 含有自定义成员、汇总小计、命名集等情况无法优化。

5 排序结果差异说明

由于数据库排序规则（如字符集、排序算法）与 Java 内存排序规则（如语言环境、空值处理）存在差异，启用配置项后可能导致排序结果与原逻辑不一致，需提前告知用户。

• 未开启优化设置项是在内存中排序：

• 开启优化设置项是在数据库中排序：

特别注意：混合排序的不一致风险

在报表 / 透视分析制作过程中，若存在 “先添加维度排序（触发 nativeOrderBy），后添加计算度量排序（无法触发 nativeOrderBy）” 的操作，可能导致：

• 第一步维度排序结果基于 SQL 下沉逻辑；
• 第二步计算度量排序结果基于内存逻辑（不满足走下沉的逻辑，会走回内存排序）。