SSAS 表格开发 DAX 与 SQL 性能答案

【问题标题】：SSAS Tabular Development DAX versus SQL performanceSSAS 表格开发 DAX 与 SQL 性能
【发布时间】：2018-08-14 19:00:52
【问题描述】：

我目前正在研究一个现有的表格模型，它有大约 150 万行。它由 SSMS DB 视图驱动并部署到 SSAS。

我的问题是哪种语言处理得更好/更快？

添加度量时，我可以在视图中创建 SQL case 语句或将度量直接放在模型中。我刚刚开始这个项目，但数据增长相当稳定，我担心模型的长期性能会随着新的字段、度量和记录不断扩大。

【问题讨论】：

优化性能是高度针对具体情况的。我不确定你的问题是否有一个好的答案。
@AlexisOlson 感谢您的评论。我完全理解。

标签： sql dax sql-server-data-tools ssas-tabular ssms-2017

【解决方案1】：

我使用以下经验法则：

在 SQL 中计算所有维度属性。切勿在 DAX 中使用任何计算列。
计算 SQL 中最复杂和最昂贵的指标。这些通常很少，例如所有计算的 2-5%。剩下的交给 DAX。

在后台，DAX 被翻译成 SQL 查询（您可以使用 DAX Studio 查看它们：https://www.sqlbi.com/tools/dax-studio/） .如果 DAX 编写正确，执行计划将与 SQL 一样高效。当然，如果您的 DAX 错误，它可能会转化为非常无效的 SQL，但这是意料之中的。

最后，只是为了正确设定期望：如果表格模型超过 10 亿条记录，则认为它是“大”的。 100M - 1B 记录之间的模型被认为是中等大小的，可能需要一些优化（基本上，你必须知道你在做什么）。任何少于 100M 的记录都是一个小模型，如果你有性能问题，要么是你的数据模型是错误的，要么是你的 DAX 不正确/无效。

【讨论】：

> “在后台，DAX 被翻译成 SQL 查询” 我猜这仅适用于 DirectQuery 模型？总的来说，与执行相同操作的 SQL 表达式相比，即使在复杂的 DAX 表达式中，导入数据的模型 (VertiPaq) 的性能也要好得多。
@Dan：VertiPaq 查询实际上也是如此。 DAX 被翻译成一种称为 xmSQL 的 SQL 风格。例如，此 DAX 代码： ADDCOLUMNS( VALUES(Product[Color]), "Sales", CALCULATE( SUM(Sales[Amount])) 将被翻译成 xmSQL 代码： SELECT Product[Color], SUM(Sales[Amount] ) FROM Sales LEFT OUTER JOIN Product ON Sales[Product_ID] = Product[Product_ID]。它的执行计划可能比类似的 SQL 查询更好或更差，这取决于其他一些因素，但通常是可比的。
我知道 xmSQL，但认为 DAX 不能比 SQL 快，因为 DAX 查询被转换为 xmSQL 没有任何意义。 xmSQL 通常是一个非常有限的 SQL 子集，由 AS 存储引擎使用。对于简单的事情，比如聚合列中的值，它实际上可以比关系数据库中的 T-SQL 查询快数千倍。
我并没有争辩说它不能 - 如果您将 xmSQL 查询与列式数据库进行比较，而将 SQL 查询与关系数据库进行比较，则可以确定它可以。有时它更快，有时它更慢，这取决于查询的性质。但是，如果两者都查询列式数据库，我看不到 DAX 与 SQL 的任何优势。它只是 SQL 之上的一个语义层。 Vertipaq 本身可能比其他列 DB 有一些优势，但那是另一回事。
VertiPaq 与柱状数据库相比具有巨大优势。它在内存中，包括表之间的关系（语义）等。只是当我阅读您对问题的回答时，您似乎在争辩说 DAX 通常并不比 SQL 快，因为 DAX 被转换为 SQL ...当然不是这样。