D365FO: Тяжелый запрос в продакшне vs. в машине для разработки

[Stitch_MS]

Есть кастомная вьюха, основанная на нескольких других вьюхах, тоже кастомных, в т.ч. с группировками и с "computed columns". Всё это работает на таблицах с миллионами записей.

Есть форма, основанная на этой вьюхе, искользуется для выверки данных помесячно. Форма загружает записи из вьюхи только после того, как юзер выберет пару значений в фильтре (месяц и год) и нажмет Apply. Эти поля покрыты индексом в базовой таблице, в той что с миллионами записей. Другие индексы в наличии.

Проблема в следующем: на машине для разработки, где данных всего раза в два меньше, чем в продакшне, октябрь открывается, скажем, за 15 секунд, ноябрь за 30, декабрь (самый тяжелый по количеству записей) за 6 минут.

В продакшне (где, казалось бы, производительность должна быть как минимум не хуже машины разработчика), октябрь хорошо если открывается через несколько минут, а-то и не октрывается совсем, декабрь всегда без исключения зависает и через час заканчивается ошибкой "... A time-out occurred in the database while the query was executing"

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

Но тысяча чертей, почему продакшн так тормозит по сравнению с обычной машиной для разработки, даже в запросах, отрабатывающих за пару десятков секунд?

[fed]

Ну например - из за большей размерности данных, запрос вместо nested loop join уходит в hash join, который при плохих раскладах может раз в 10 больше времени потребовать. Или в Prod статистика битая например.
В общем - на мой взгляд есть смысл тестировать в DEV только если у вас свежая база с Prod в среду разработки перенесена.