1 背景

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

2 配置项说明

3 可优化场景及示例

以下场景可通过配置项触发排序下沉，优化性能（附 MDX 与优化后 SQL 对比）：

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

3.2  原始度量全局排序优化

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

3.4 维度排序和度量组内排序组合序，只有当除了最后一个维度都设置了维度排序，才可以优化；其它组合情况无法排序

3.5 由于计算度量是在内存中计算，所以依据计算度量的排序无法优化；由于度量过滤也是走计算度量的逻辑，因此含有度量过滤的场景也是不能优化。

6）含有自定义成员、汇总小计、命名集等情况无法优化。

7）由于数据库的排序规则和内存中java的排除规则存在不同，因此启用这两个选项后排序结果有不同。

四、无法优化的场景

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

• 计算度量排序：计算度量需内存计算，无法下沉。
• 含度量过滤的场景：度量过滤依赖计算度量逻辑，无法下沉。
• 复杂元数据场景：含自定义成员、汇总小计、命名集等元数据的查询。

五、排序结果差异说明

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

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

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

• 第一步维度排序结果基于 SQL 下沉逻辑；
• 第二步计算度量排序结果基于内存逻辑；
• 最终排序结果与预期偏差，需在前端交互中增加提示或限制此类混合操作。

总结：本次优化通过排序下沉显著提升多维查询性能，但需明确适用场景与限制，避免因配置启用或混合操作导致结果不一致。建议在文档中补充 “配置生效条件”“排序差异示例” 等说明，并在前端交互中增加风险提示。