Question

如果我希望在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条款，但很快我意识到它完全是为了其他东西。

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

Answer 1

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

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

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

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

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

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

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

Answer 2

据我所知，如果您想缓存查询结果并提高整体吞吐量，那么切片器会更好，但如果您只关心单个查询性能，那么您可以通过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＆＃39;能够缓存计算结果，这意味着长期性能会降低： http://cwebbbi.spaces.live.com/blog/cns!7B84B0F2C239489A!3057.entry

在MDX中选择vs Slicer

2 个答案: