такой запрос? разбивать на несколько cte?
думать самому в каком порядке джойнить и прописывать хинт FORCE ORDER?
Все в зависимости от того, что делает запрос. Если у тебя 40 джоинов, то скорее всего в базе кривая архитектура
это построение отчета, с архитектурой все скорее всего норм)
SQL SERVER? в любом случае смотрите в сторону упрощения и предварительного помещения некоторых особо тяжелых джоинов во временные структуры, либо материлизованные предстваления
да, sql server тогда смотреть в сторону вьюх и CTE?
нет, CTE вам здесь точно не помогут, это просто сахар в SQL Server, временные таблицы
а FORCE ORDER стоит попробовать?
Взять актуальный план и анализировать узкие места. Обратить внимание на индексы, рекомендованные оптимизатором, если таковые есть. Обратить внимание на значение свойства "Reason For Early Termination Of Statement Optimization" После этого уже можно думать на какие фрагменты разбивать запрос и разбивать ли вообще. Применение FORCE ORDER наобум обычно результата не дает.
вот в целом безвредные советы, вам нужен SQL Tuning: The Wise Use of Temporary Tables (#Temp) https://www.toptal.com/sql-server/sql-database-tuning-for-developers
с индексами все норм, везде seek, проблема в том, что из-за порядка джойнов в плане запроса во многих места Number of Rows Read многократно выше, к примеру мог бы быть в районе 500, а по факту 90к
Есть хинты
"Везде seek" не критерий оптимальности. Например, cross (outer) apply частенько дает NL + Index Seek, но по производительности это не лучший вариант. В общем, чтобы давать конкретные рекомендации нужен актуальный план.
попробую вообще где-то слышал, что на больших запросах статистика так себе помощник, что на что большом кол-ве джойнов оптимизатор не будет работать давать нормальный план запроса
На тех данных, которые не могут изменить свою селективность или количество, да
Не на больших запросах, а на больших таблицах. Из-за ограничения в 200 шагов гистограммы. И я уже вам писал как посмотреть нашел ли оптимизатор оптимальный план
Обсуждают сегодня