3

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

因此，抛开其他方面不谈，我对这些查询的一般性能、要牢记的任何基准或最佳实践以及在什么情况下选择哪一个感兴趣。

4

2 回答 2

1

与优化器问题一样，答案是：视情况而定。我会说 WHERE 在许多情况下更快，但在某些情况下 subselect 更快。

优化器通常不会被供应商记录在每个细节上（即使某些文档比其他文档更多，而 Analysis Services 是具有较少文档优化器的引擎的典型示例）。我认为他们的代码中有很多很多规则，比如“如果这个和那个，但不是第三种条件，那么就沿着这条路线走”。而且这种情况不断变化，因此任何文档都会因每个修补程序或多或少而过时。

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

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

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

无论如何，在许多情况下，性能差异是如此之小以至于它是不相关的。

最后，可用于分析服务优化器的最佳文档是分析服务查询引擎开发人员之一的旧博客，网址为http://sqlblog.com/blogs/mosha/default.aspx。这是一个博客，它不是很系统，只是收集了一些随机的优化器行为样本及其背后的原因。

于 2014-11-27T09:54:53.497 回答
1

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

回答以下问题，以下信息来自 Chris Webb

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

要回答最初的问题：使用您找到的任何一个都可以为您提供最佳查询性能并返回您想要查看的结果。一般来说，我更喜欢 Where 子句（不推荐使用）；原因是虽然子选择在某些情况下最初可能执行得更快，但它限制了 Analysis Services 缓存计算结果的能力，这意味着从长远来看会降低性能：http: //cwebbbi.spaces.live.com/blog/ cns!7B84B0F2C239489A!3057.entry

于 2014-12-05T10:35:58.220 回答