![](https://img-blog.csdnimg.cn/direct/a118ad6862a64f03a4d8006b1c287be2.jpeg?x-oss-process=image/resize,m_fixed,h_224,w_224)
研究《DAX查询计划 白皮书》中的案例
文章平均质量分 97
以当前的 DAX 版本,重新研究 《DAX 查询计划白皮书》中的案例,定位性能瓶颈,理解优化思路。
apinerand
别看我,看文章。
展开
-
研究《DAX查询计划 白皮书》中的案例(五)优化方案3
这是本系列的最后一个优化方案,这一篇的优化方案3是所有方案中最优秀的,它解决了优化方案2中产生的[RowNumber] 问题,使整个底层计算过程中全部步骤都没有出现数据量超过万行的情况,使性能获得了极大的提升!原创 2024-05-19 21:15:21 · 1195 阅读 · 1 评论 -
研究《DAX查询计划 白皮书》中的案例(四)优化方案2
优化方案1将原始方案的计算效率提高了 90% 以上,而白皮书认为这还不是最好的方案,原作者给出了另外两个更好的方案,这两个算法都不再基于对计算要求的直接理解,更换了 DAX 写法。本篇分析白皮书提供的优化方案2,并与优化方案1和优化方案(番外)进行比较,进一步认识性能优劣的底层原因。原创 2024-05-17 00:05:18 · 1202 阅读 · 0 评论 -
研究《DAX查询计划 白皮书》中的案例(三)优化方案(番外)
上一篇给出的优化方案中使用了两个 FILTER 函数,而如果将两个 FILTER 函数合并成一个,可以使计算性能进一步提升,但是白皮书中并没有记录该方案。为了查明原因,比较优劣,本篇先将白皮书的其他优化方案抛开,先研究一下这个番外优化方案的秘诀。原创 2024-05-13 23:55:27 · 839 阅读 · 0 评论 -
研究《DAX查询计划 白皮书》中的案例(二)优化方案1
上一篇文章中介绍了初始方案的查询计划,找到了性能瓶颈来自 FILTER 的一参使用 Sales 整表,在底层执行时需要计算数据量巨大的交叉表,导致公式引擎部分耗费大量时间,确定了改进方向是想法提高 FILTER 的性能,减少迭代对象的势。不过白皮书给出的第一个方案并没有直接从减少 FILTER 迭代对象的势入手,而是采取了 CALCULATE+FILTER 的写法,这也是许多初学者可能采取的方案。那么本篇文章将继续通过理解查询计划,了解其底层执行过程,分析其优劣势。原创 2024-05-12 21:18:48 · 348 阅读 · 0 评论 -
研究《DAX查询计划 白皮书》的案例(一)初始方案
SQLBI 网站上提供的[《White paper: Understarnding DAX Query Plans》,发布于2023年7月17日,距今已超过10年,随着DAX 版本不断更新优化,原文中关于查询计划的描述已不再符合当前实际情况。为充分理解、运用该文阐述的分析方法,以当前 DAX 版本运行文中案例,尝试理解查询计划及优化思路。原创 2024-05-10 22:34:45 · 822 阅读 · 0 评论