优化MDX查询性能：能否创建维度加速度量过滤查询？

你当前的性能问题根源很明确：用FILTER遍历所有[Event Work Order ID]成员，并且对每个成员实时计算[Days Open]度量来判断是否符合条件——这属于运行时逐行计算，当工单数量较多时，每一条工单都要临时计算度量值，完全没利用Cube的预计算优势，自然会拖慢查询。

把[Days Open]和[Days Overdue]转化为可过滤的维度，本质是把查询时的计算提前到Cube构建阶段完成：

• 基于底层数据的Days Open和Days Overdue字段，你可以创建离散的维度成员：要么直接用原始数值（如果数值范围不大，比如0-250），要么按区间分组（比如0-30天、31-60天…241-250天）。
• Cube构建时会预先把每个工单ID和对应的维度成员关联起来，同时生成对应的索引结构。

这种优化会带来显著的性能提升：
当你用维度过滤替代FILTER时，查询会直接利用Cube的预计算索引，不需要再逐个工单计算度量值。数据量越大，这种方式的效率优势越明显。

举个修改后的查询示例：
假设你创建了[Days Open Dimension]，成员是具体的天数，那你的查询可以完全去掉低效的FILTER：

Member [Measures].[Work Order Measure] AS 
SUM(
  [Days Open Dimension].[Days Open].&[1]:[Days Open Dimension].[Days Open].&[250],
  [Measures].[Work Order Count]
)

如果用区间分组的维度（比如[Days Open Bucket]），代码会更简洁：

Member [Measures].[Work Order Measure] AS 
SUM(
  [Days Open Bucket].[0-250 Days],
  [Measures].[Work Order Count]
)

最后补充两个小建议：

• 如果Days Open的数值范围很大，优先用区间分组，这样维度成员数量更少，Cube的存储和查询性能都会更好。
• Days Overdue可以用完全相同的方式处理，创建对应的维度即可。

内容的提问来源于stack exchange，提问作者James Culshaw