Часто мы видим что простое, прямое решение — не лучшее, и не потом что оно плохое — просто у нас уже в базе пару миллионов строк, хостинг недорогой, и сайт начинает вести себя неприлично. Зависание более чем на 1 секунду на запрос — это недопустимо для небольших сайтов. Дальше пример и шаги как работать со сложным медленным запросом
Наш начальный запрос
Слишком длинный чтобы понять сразу что не так, поэтому просто посмотрим и начнем бить
Базовый запрос
Время выполнения 0.01 это наш запрос до внесения «до…» джоинов
Один джоин тяжелый
Еще вменяемое время хотя уже тяжелый джоина по тегам тура (таблица pivot_tour_new_tour_type)
Два джоина нас убили
Таблица тегов отеля (pivot_hotel_new_tour_type) присоединилась к запросу и просто все улетело в 5-6 секунд. Это наша проблема! *источник найден значит будет обезврежен
Убираем запрос тегов во внешний запрос
Суть в том что прежде чем выбрать 9 — наша мегатаблица строится со всеми тегами, со всеми всеми строками, потом группируется, и потом только… не надо так, а надо вынести все что можно наружу
Добиваем общий вид
Добавляем условие если нужно конкретные теги — и запросик всего 0.02 уже)
спасибо за инфу! подскажите пожалуйста, можно ли место INNER JOIN использовать group by?
полный запрос какой будет?
если просто посчитать то вообще разный план запросов — т.е. group by вы по умноженному значению таблиц сделаете — и это всЕ)