andreysssВсем привет. Прошу помочь. Не получается переделать сложный запрос с тремя LEFT JOIN в несколько простых. Суть в том, что группирование кушает много ресурсов, на столько много, что выборка из 115 тыс записей делается более 3 секунд и съедает все ресурсы. Если группировку убрать, то запрос проходит за 0,15 сек. Но без группировки нельзя в данном запросе. Если использовать несколько простых подзапросов, то можно избавиться от GROUP by. Предполагаю для этого нужно сделать подзапрос jb_photo с LIMIT 1. Сколько не пытался оформить в несколько простых, ничего не вышло. Да впринципе с группировкой разберусь, главное как то всё это переделать в простые запросы. Union all не получилось сделать, т.к. количество столбцов различается (так пишет мускуль).



Дык а что тут думать!!!!

у тебя есть запрос

запрос(0.15сек) + джоин картинок, которых дофига, и групировка что осталась одна случайная

переделываешь в

1)
select *
from
(запрос 0.15 сек)t left join photos ..... group by Для того чтоб по одной фотке
---думаю самый худший вариант

2)
--полудше

select *, (select photo_name from photos where Foreign_key = t.id)

from (select 0.15) t

3)
--возможно быстрей всего получиться
1 select 0.15
построить список айдишников
2 запросом найти select foreignkey,photo_ name from photos where foreignkey IN (1,2,3 .. 20)

раз данных много, то пытаться получать для каждого айди по 10-50 фоток и пытом отсеивать...здаёться мне это тупиковым путём

ити надо именно в сторону , дабы сразу не получать лишнего....

andreysss,

обработка склю запроса

FROM -определение источника данніх
WHERE -фильрация
SELECT выбор нужной части данных

GROUP BY + агрегаты(агр-ие ф-ии) секции селект
HAVING +фидбьо плсде шоупиолвки
ORDER BY сортировка

последние три - это подготовка выдачи результата, данные идут на выход по мере
готовности. понятное дело что если сортировка без индекса пойдёт, то навыход пойдут данные
только после полной сортировки

если есть переменные, то они обрабатываються на последнем этапе


====
вкачестве оптимизации, какойто отдельный шаг, может поддымться вверх по списку
но не в низ

пример класика жангра

select * from t1,t2 where t1.id=t2.id
в лоб, это надо умножить две таблицы, и из полученой тоны записей отобрать по секции веар
реально, оптимизатор оптимизирует, что будет идентично джоину, и выборка будет идти
полная из меньшей таблицы, а из большей по индексу(если есть) только нужных записей.