近似去重反而更慢？

一个反直觉的测试结果

做 DAX 性能优化的人，看到 APPROXIMATEDISTINCTCOUNT 这个新函数，第一反应多半是：终于有办法治 DISTINCTCOUNT 这个性能杀手了。

但最近一轮实测下来，结论有点打脸——在某些场景下，近似去重反而比精确去重更慢。

这不是段子，而是引擎层面的真实差异。

测试环境

用一个非常基础的 Direct Lake 语义模型，数据是纽约出租车数据集的 2017 年部分：

• 表行数：约 1170 万行
• 测试列：VendorID
• 该列不同值数量：只有 2 个

建了两个度量值做对比：

1. DISTINCTCOUNT('green_tripdata_2017'[VendorID])
2. APPROXIMATEDISTINCTCOUNT('green_tripdata_2017'[VendorID])

冷缓存下的性能对比

对 85562 行数据做聚合，冷缓存条件下：

精确去重版本

• 查询总耗时：188ms
• 单次扫描 CPU 时间：110ms
• 内存占用：约 8MB

近似去重版本

• 耗时和资源消耗都明显更高（原文测试图显示差距不小）

也就是说，这个本该更快的函数，在低基数列上完全跑不过原版。

为什么会这样？

关键在于引擎对 DISTINCTCOUNT 有一层针对低基数列的特殊优化，而 APPROXIMATEDISTINCTCOUNT 走的近似算法路径没法复用这套优化。

具体来说：

• 当列的不同值很少时，精确去重可以走位图 / 哈希等紧凑结构，扫描成本极低
• 近似算法为了保证精度，需要维护额外的统计结构（如 HLL 的寄存器），反而带来固定开销
• 基数越低，这个固定开销相对于精确计算越不划算

什么时候该用哪个？

结合上次那篇讲 APPROXIMATEDISTINCTCOUNT 优势的文章，可以总结出一条实用判断规则：

• 高基数列（几十万、上百万不同值）：用 APPROXIMATEDISTINCTCOUNT，收益明显
• 低基数列（几十、几百个不同值）：老老实实用 DISTINCTCOUNT，别折腾
• 对精度有硬要求：无论基数高低，都用 DISTINCTCOUNT

给国内 BI 同行的一句话

新函数不等于万能药。做性能优化时，先测再换，别被函数名里的 "Approximate" 和 "优化" 字眼带偏。低基数列上，原版 DISTINCTCOUNT 依然是更稳的选择。