SUMMARIZECOLUMNS 的疑似 bug（3）总计行是否关键点_summarizecolumns 结果不对-优快云博客

SUMX 在 SUMARIZECOLUMNS 非总计行的底层计算过程

上一篇介绍了在总计行中出现与理论预期不符的结果，通过物理查询计划了解其底层计算过程，猜想是否 SUMMARIZECOLUMNS函数对总计行的计算存在什么特殊算法，本篇验证在非总计行中进行计算的情况，以帮助判断总计行是否是关键点。

SUMMARIZECOLUMNS 的疑似 bug（1）引言
 SUMMARIZECOLUMNS 的疑似 bug（2）SUMX 在总计行
 SUMMARIZECOLUMNS 的疑似 bug（3）总计行是否关键点
 SUMMARIZECOLUMNS 的疑似 bug（4）验证触发条件
 SUMMARIZECOLUMNS 的疑似 bug（5）最终结论

实验设计

很简单，在上一篇的基础上，从可视化对象（矩阵）的行标题中，去除 Dates[Month Num] ，仅保留 Dates[Year] ，观察计算结果并分析计算过程。

计算结果与上一篇中总计行的数值一样，说明在非总计行上也会发生相同的情况，因此可以否定掉SUMMARIZECOLUMNS总计行的计算存在特殊算法这个猜想。

在非总计行是如何计算出这些结果的，下面仍然通过分析物理查询计划来探究。

DAX 查询

EVALUATE
SUMMARIZECOLUMNS (
    Dates[Year],
    TREATAS (
        {
   
    ( 2019, 1 ), ( 2019, 2 ), ( 2020, 11 ), ( 2020, 12 ) },
        'Dates'[Year],
        'Dates'[Month Num]
    ),
    "Total", [SumxBug]
)

这次没有添加 ROLLUPADDISSUBTOTAL函数，甚至没有 Dates[Month Num] 做参数

存储引擎

2个 xmSQL 查询

1、VQ1，F1V0

按切片器固化筛选器从 Dates 表中获取 Year 列的不重复值

SELECT
    'Dates'[Year]
FROM 'Dates'
WHERE
     ( 'Dates'[Year], 'Dates'[Month Num] ) IN {
   
    ( 2020, 12 ) , ( 2019, 2 ) , ( 2020, 11 ) , ( 2019, 1 ) };

2、VQ2，F2,V1

固化筛选器又被破坏了，分别以 Year = {2019,2020} 和 Month Num = {1,2,11,12} 做条件，从 DFact 扩展表中按 Dates[Year] 和 Dates[Month Num]分组汇总 DFact[Amount]

SELECT
    'Dates'[Year],
    'Dates'[Month Num],
    SUM ( 'DFact'[Amount] )
FROM 'DFact'
    LEFT OUTER JOIN 'Dates'
        ON 'DFact'[Date]='Dates'[Date]
WHERE
    'Dates'[Year] IN ( 2019, 2020 ) VAND
    'Dates'[Month Num] IN ( 12, 1, 2, 11 ) ;