Subselect vs Slicer в MDX

Question

Если я хочу, чтобы мои результаты оценивались в контексте любого кортежа в MDX, , но не хотите, чтобы этот фрагмент был частью результатов, я использую один из следующих двух вариантов.

1. подвыбор

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

2. SLICER

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

Третий вариант, который пришел мне на ум EXISTS положение, но вскоре я понял, что он имел в виду что-то другое в целом.

Таким образом, другие аспекты в сторону, я заинтересован в общем производительности этих запросов, любые тесты или лучшие практики, которые будут иметь в виду и который один пойти на обстоятельства, при которых.

Answer 1

Как и в случае с вопросами оптимизатора, ответ: это зависит. Я бы сказал, что во многих ситуациях быстрее во всех случаях, но есть случаи, когда subselect быстрее.

Оптимизаторы обычно не документируются каждой деталью поставщиками (даже если некоторые из них более документированы, чем другие, а Analysis Services - типичный пример движка с менее документированным оптимизатором). Я бы подумал, что в их коде есть много правил, например «если это и это, но не третье условие, тогда идите по этому пути». И это постоянно меняется, поэтому любая документация будет устаревать с более или менее каждым исправлением.

Как уже говорилось, ситуация для многих реляционных движков немного лучше, где для SQL Server вы можете, по крайней мере, показать план, который более или менее понятен. Но даже там вы не знаете, почему именно оптимизатор выбрал этот план, а не другой, и иногда приходится пробовать несколько подходов, чтобы оптимизировать на другом пути (например, с помощью индекса ...). И новый выпуск SQL Server может обрабатывать вещи по-другому, надеюсь, лучше в большинстве случаев, но, возможно, хуже в нескольких редких случаях.

Это явно не ясный и документированный способ написания кода, а просто проб и ошибок.

Подводя итог: Вам придется протестировать свой куб и ваши типичные запросы.

В любом случае разница в производительности настолько мала, что это не имеет отношения к делу.

И, наконец, лучшая документация, доступная для оптимизатора служб Analysis Services, представляет собой старый блог одного из разработчиков механизма запросов служб Analysis Services по адресу http://sqlblog.com/blogs/mosha/default.aspx. Это блог, это не очень систематический, а просто набор некоторых случайных образцов поведения оптимизатора с причинами этого.

Answer 2

Насколько я знаю, если вы хотите кэшировать результаты своих запросов и улучшать общую пропускную способность, то лучше использовать slicer, но если вы просто заботитесь о производительности одного запроса, вы можете получить более высокую производительность с помощью подзапроса.

Отвечая на вопрос ниже, Следующая информация от Chris Webb

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/c1fe120b-256c-425e-93a5-24278b2ab1f3/subselect-or-where-slice?forum=sqlanalysisservices Прежде всего, нужно сказать, что подзапросы и где положение делают две разные вещи - они не взаимозаменяемы при любых обстоятельствах , они могут возвращать разные результаты, а иногда одни работают лучше, иногда другие делают, потому что они могут привести к созданию разных планов запросов. Один метод не всегда «лучше», чем другой на всех кубах, и любые различия в производительности могут сильно измениться с пакета обновления до пакета обновления.

Чтобы ответить на исходный вопрос: используйте то, что вы найдете, дает вам лучшее качество запросов и возвращает результаты, которые вы хотите увидеть. В целом я предпочитаю предложение Where (не устарело); причина в том, что, хотя в некоторых случаях подзапрос может выполняться быстрее изначально, он ограничивает способность аналитических служб кэшировать результат вычислений, что означает более медленную работу в долгосрочной перспективе: http://cwebbbi.spaces.live.com/blog/cns!7B84B0F2C239489A!3057.entry