Или вот еще.. есть SQL не-очень-хитрый-запрос. На нашем MS SQL

сервере, что в докере поднят чуть ли ни с минимальными ресурсами, он выполняется 1.5-3.5 сек. На проде, на родном Виндовз Сервере, с ресурсами в 10 раз больше (другие запросы у них в 10 раз быстрее), вот этот специфичный не-очень-хитрый-запрос выполняется 25 МИНУТ!!! 1.5 сек против 25 минут!!! Добавление индексов по рекомендацим профайлера УХУДШАЮТ время до 35 мин. Админы БД сервера сертифицированы Мелкосовтом по последнему уровню. Они делают БОЛЬШИЕ глаза и разводят руками.. Ну вот какой курс может о таком рассказать?
Ну да, базы идентичны - обе подняты с одного и того же дампа. Настройки бд сервера.. уже все перетыкали, даже идей нет

В локальном окружении свежевосстановленном из бэкапа нет ни процедурного кэша, ни, на сколько я помню, табличных статистик. Поэтому сравнивать боевой сервер с локальным не всегда просто. Анализ плана в таких случаях всегда помогает. Ну и профайлер в помощь. Все эти инструменты у мс куда круче чем у пг, так что надо радоваться благам)

Это первое о чем подумали, подняли в выходные тестовую БД на подовом сервере, востановили из дампа. Та же фигня. Сейчас единственная мысль - много памяти у SQL сервера включает там какие-то "супер оптимизационные механизмы", что приводят вот к такому. Ну и это.. я не проффи админ по бд, да и вообще там рулят админы заказчика, у нас прямого доступа нет по соображениям высокой-безопасности! (их безопасники - зверюги еще те). Так что.. могу только пересказывать с их слов что они пытались делать. По их словам и планы анализировали, и профейлили не раз, и даже индексы по другому расставляли (типа, чуть менее оптимально). В общем.. пришлось эмулировать with, union all и where в js, закачивая все в память.. хорошо хоть влезло в 1.6 Гига и таблицы не из тех что растут со временем..

Может блокировки на проде способствуют такому времени? Или исключили такой вариант уже

Исключили - тестовая БД вообще в моноюзере работала. В общем пару недель поковыряли, плюнули и обошли. Не, ну можно было еще полностью архитектуру переделать, даже были мысли.. Но.. сумма контракта такое не вмещала 8)

У меня просто часто аналогичная проблема вспывала, выяснилось, что у нас по дефолту даже при селекте другим юзером ставилась блокировка. А запрос был очень тяжёлый. И второй запрос затрагивающий ту же таблицу висел в ожидании первого. Решили ессно в лоб с with (nolock) со стороны параллельных запросов. Другие рекомендации нам не помогали, что забавно. Но уже, с учётом ухода мелкомягких, это меньшее из зол, конечно. Думаем о миграции..

Самое забавное, если переписать с with на временные таблицы - все начинает летать как и положено, меньше секунды. Однако... такие запросы имеют неприятность приходить пиками, и когда надо создать 100 временных таблиц приличного размера почти одновременно, сервак затыкается с гарантией. Т.е. разовый запрос вроде - все хорошо, а нагрузочное тестирование - полный облом

Как правило, если копать долго и глубоко, накопать можно. За 25 лет написания бэкендов видел раза три, когда объяснений вообще ноль. Ну теоретически баг какой-то может быть, изредка. Ваша ситуация выглядит как рейсинг лок-таймаут-сброс- продолжение где-то. Слишком большая разница во времени. Я бы копал в i/o locks. Но забить и обойти часто тоже вариант. Может, кто-то лочит и не закрывает транзакцию?

А место на дисках достаточно кстати? Такое теоретически можно возникнуть из-за нехватки места из-за растущей tempdb раз уж речь о временных таблицах

А не понятно как копать. Нас не пускают к серверам клиента. Только через сообщение админу "а попробуйте вот это", в ответ "не вышло, вот логи". Это диагноз по фотографии считай. По этой же причине саппорт мелкомягких не подключали. Не, точно проблема не в локанье. Там что-то с построением временных индексов, вроде.. Не, места хватает памяти тоже, затык на уровне процессора (100%) загрузка. Ладно, обошли и обошли. Забыть хочется как страшный сон 8) Теперь бы с IndexDB хоть что-то наковырять... Ну или думать как и это обходить..

Вариант с забыть тоже норм) К сожалению, часто попадали с другими продуктами MS ( особенно Dynamics ) на нерешаемые баги с нашей стороны, решений в сети нет, и единственный выход - тикет в MS. А это можно сказать вообще черная дыра.

Еще подозреваем, что это какие-то баги при индексировании по uniqueidentifier.. Он у MS не так давно реализован, детские болезни могут быть.. Но.. на него завязано пару ключевых фич, тоже перекраивать архитектуру дорого и долго. Саппорты крупных компаний.. по реально сложным вопросам нам ни разу не удалось получить решения.. Ну.. разве что "а поменяйте как вы железо серверное, глядишь поможет" 8)

Скорее "пробовали перезапустить сервис / выключить и включить?" ( Это кстати реальная рекомендация от вендора часто была )))