Доброго всем дня. Не могу понять причины тормозов.

РС ЦеныНоменклатурыМагзаинов, измерения Магазин, Номенклатура, Характеристика. Объем 3,5М записей. Платформа 8.2.19, 8.3.7 (смотрел на трех разных серваках, сиквел везде 2008)
Делаем "голый" СрезПоследних(Дата, Магазин) - время выполнения более минуты.
Индексы есть (в т.ч. и на измерения), перестроены, статистика обновлена, ТиИ делалось.
sp_MSforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN', dbcc updateusage, dbcc freeproccache делал

Смотрю запрос (рис. 1 http://www.pixic.ru/i/00A1S0C421D9p293.png), план (рис. 2 http://www.pixic.ru/i/X001O0j4G1j9Q2w5.png). Вижу что второй джоин трансформировался в Nested Loop, который ожидал
мало строк, а на выходе получилось 7М (2х объем регистра).
Если в запрос трансформировать, добавив либо TOP (в самом вложенном запросе, где идет поиск максимума по периоду), либо
самый верхний INNER JOIN dbo._InfoRg2510 T6 WITH(NOLOCK) заменить на
INNER MERGE JOIN dbo._InfoRg2510 T6 WITH(NOLOCK)
то ситуация меняется кардинально (рис.3 http://www.pixic.ru/i/S0W1G0u4R1N952f6.png), выборка та же, время выполнения 2 сек.
Если уйти от среза, генерируемого платформой, и написать тот же запрос вручную, то те же 2 сек на выходе.

Вопрос. Что можно сделать, чтобы типовой СрезПоследних попадал в план запроса, аналогичный рис.3?

ставь самый последний скуль от мелкомягких и будет тебе счастье.

это вроде бы патчем лечили, ой, сервиспаком самым свежим. Но можно 2014 ставить и не сильно искать непосредственно нужный сервиспак

(1) По каким ключевым словам можно погуглить?

(0) Вай-вай-вай.

Откуда такой красивый рисовальщик планов запросов?
Или это типовой от sql2014?

(2) вот недавнее обсуждение
Одна и та же база УПП под 8.2 и 8.3 распределяет затраты по-разному

(3) +1, тоже понравился, интересно откуда

может нужно включить использование таблиц итогов для регистра сведений

(0)
Использовать обычные (не периодические) регистры сведений и их комбинации для таблиц >>1 млн. Ну запросы придется писать а ля SQL, но время будет минимальным. Есть даже складские конфы где на них все построено

(3) Это тулза SQL Manager 2008 for SQL Server, из семейства продуктов EMS
(6) Основная платформа пока 8.2, поэтому нет таблиц итогов для РС.

SQL 2008 догнал до последнего СП4, снова обновил статистику и проч. - та же фигня. План запроса не меняется.

Верно ли я понимаю, что ошибка именно в статистике, что построитель плана не верно учитывает количество строк, которые появятся в верхнем (Т6) джойне? Ведь если принудительно указать режим, то и план становится коротким, и оценка (Estimated Rows) становится близка к реальной, да и вообще ляпота и благолепие наступает.

может убрать "по позиции регистратора" из периодичности и оставить день??

да и вообще попробовать на последних платформах после реструктуризации, даже без таблицы итогов

Развернул на макете 2012СП1 сиквел, загрузил туда базу через выгрузку, обновил статистику - та же хрень. Ошибается план.
Завтра попробую 2014, может там лучше будет. Хочу понять в чем косяк.

(11) был подобный случай, я так и не смог понять причину такого поведения. Уж и над статистикой медитировал, но все бестолку.

(12) Самое обидное, что добавлением ключевого слова MERGE в запрос все летает. Объем таблицы то по меркам сикловодов тьфу, а тупка значительная.

Потыкал еще -Т 4199 и sp_create_plan_guide, только ничего не изменилось (но тут уж наверняка я что-то не так делал).

(13) Более всего обидно то, что не понятно, как такую ситуацию расследовать и исправлять.

В итоге выиграл макет с 2014СП1 Сиквелом. План запроса там строится корректным, в т.ч. ожидаемые количества строк совпадают с реальными.

(16) -> (10)

потому как трансляция виртуальных таблиц в настоящие скуль-запросы меняется от платформы к платформе

(18) Платформу не менял, 8.2.19. Запросы 1с-ка какие лепила, такие и лепит, там претензий нет. Построитель запроса ошибался.

*Построитель плана запроса

(19) ну так я про то и говорю. может в 1с эту ситуацию рассмотрели, и платформа в более новой версии лепит другой запрос в подобной ситуации, на которой построитель плана не ошибается. подобное было, например, с 5 субконто и переходом 8.1-8.2, только в другую сторону. Потом поправили. :)

(21) Да не, платформу потом протестировал и 8.2, и 8.3.6,7,8 - запрос один и тот же, ничего не меняется.