1 背景

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

2 配置项说明

...

3 可优化场景及示例

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

3.1

...

select [Measures].[Store Sales] on columns,
non empty nonemptysubset( orderex(
    nonemptycrossjoin( nonemptycrossjoin( [部门].members, [行业].members), [收入类型].members)
, [行业].currentMember.caption, desc
), 0, 100 ) 
on rows from [cube]

优化后 SQL：

...

select 部门, 行业, 收入类型 from ...... group by 部门, 行业, 收入类型 
order by 部门 desc, 行业 desc, 收入类型 asc  limit 100

2. 原始度量全局排序优化

MDX 示例：

...

select [Measures].[Store Sales] on columns,
non empty nonemptysubset( orderex(
    nonemptycrossjoin( nonemptycrossjoin( [部门].members, [行业].members), [收入类型].members)
, [Measures].[Store Sales], bdesc
), 0, 100 )
on rows from [cube]

优化后 SQL：

...

select 部门, 行业, 收入类型, sum(Store Sales) from ...... group by 部门, 行业, 收入类型 
order by sum(Store Sales) desc, 部门 asc, 行业 asc, 收入类型 asc  limit 100

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

支持维度排序与原始度量排序的组合下沉（示例略，逻辑为多条件排序组合）。

4. 维度排序与度量组内排序组合优化（有限条件）

...

纯维度排序支持性能优化

Image Added

3.2  原始度量全局排序优化

Image Added

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

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

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

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

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

四、无法优化的场景

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

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

五、排序结果差异说明

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

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

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

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

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