在MDX中选择vs Slicer

时间:2014-11-26 11:46:09

标签: ssas mdx ssas-2012 ssas-tabular

如果我希望在MDX中的任何元组的上下文中评估我的结果,但不希望这个元组成为结果的一部分,我使用以下两个选项中的任何一个。

1。子选择

SELECT [Measures].[SomeMeasure] ON 0,
[DimName].[HierName].children ON 1
FROM
(SELECT foo.bar.&[Val] ON 0 FROM
[MyCube])

2。切片机

SELECT [Measures].[SomeMeasure] ON 0,
[DimName].[HierName].children ON 1
FROM    
[MyCube]
WHERE (foo.bar.&[Val])

我想到的第三个选项是EXISTS条款,但很快我意识到它完全是为了其他东西。

所以,除了其他方面之外,我对这些查询的一般 性能 感兴趣,要记住任何基准或最佳实践以及要采用哪种方法在哪种情况下。

2 个答案:

答案 0 :(得分:1)

与大多数优化问题一样,答案是:这取决于。我想说在许多情况下WHERE更快,但有时候subselect更快。

供应商通常没有向每个细节记录优化程序(即使某些文档比其他文档更具记录性,而Analysis Services是具有较少文档化优化程序的引擎的典型示例)。我认为他们的代码中有很多很多规则,例如"如果这个和那个,但不是第三个条件,那么沿着那条路线去#34;。并且这会不断变化,因此任何文档都会过时或多或少地使用每个修补程序。

如上所述,对于许多关系引擎来说情况要好一些,对于SQL Server,您至少可以显示一个或多或少可理解的计划。但即使在那里你也不知道为什么优化器选择这个计划而不是另一个,有时必须尝试几种方法来将优化器放在另一条路径上(比如使用索引,......)。新版本的SQL Server可能会以不同的方式处理事情,希望在大多数情况下更好,但在极少数情况下可能会更糟。

这显然也不是编写代码的清晰且有文档记录的方式,而只是反复试验。

总结:您必须使用多维数据集和典型查询进行测试。

无论如何,在许多情况下,性能差异太小而且不相关。

最后,可用于Analysis Services优化器的最佳文档是http://sqlblog.com/blogs/mosha/default.aspx的一个Analysis Services查询引擎开发人员的旧博客。这是一个博客,它不是非常系统化,而只是一些优化器行为随机样本的集合及其背后的原因。

答案 1 :(得分:1)

据我所知,如果您想缓存查询结果并提高整体吞吐量,那么切片器会更好,但如果您只关心单个查询性能,那么您可以通过subselect获得更好的性能。

回答下面的问题, 以下信息来自Chris Webb

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/c1fe120b-256c-425e-93a5-24278b2ab1f3/subselect-or-where-slice?forum=sqlanalysisservices 首先,需要说的是子选择和Where子句做两件不同的事情 - 它们在所有情况下都不可互换,它们可能会返回不同的结果,有时一个表现更好,有时另一个表现更好,因为它们可能导致生成不同的查询计划。一种技术并不总是“更好”。在所有多维数据集上,所有多维数据集的性能差异都很大,而且从Service Pack到Service Pack的性能差异很大。

回答原始问题:使用您找到的最佳查询效果并返回您想要查看的结果。一般来说,我更喜欢Where子句(已弃用);原因是虽然在某些情况下,子选择最初可能会表现得更快,但它限制了Analysis Services'能够缓存计算结果,这意味着长期性能会降低: http://cwebbbi.spaces.live.com/blog/cns!7B84B0F2C239489A!3057.entry