1 背景

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

2 配置项说明

...

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. 维度排序与度量组内排序组合优化（有限条件）

...

四、无法优化的场景

3 可优化场景

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

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

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

Image Added

3.2  原子度量全局排序优化

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

Image Added

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

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

Image Added

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

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

Image Added

4 无法优化的场景

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

• 计算度量排序：计算度量需内存计算，无法下沉。
• 含度量过滤的场景：度量过滤依赖计算度量逻辑，无法下沉。

...

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

5 排序结果差异说明

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

...

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

Image Added

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

Image Added

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

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

• 第一步维度排序结果基于 SQL 下沉逻辑；

...

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