можно вынести
$var1 = '<models 1-2>';
$var2 = '<models 3-10>';
$varN
но это все равно N запросов (как я понял каждый макрос живет сам по себе и сам запрашивает данные. Если не так, то ссорян)
Потому и вопрос - а как можно дернуть всех за 1 раз, а потом распихать эту выдачу по странице.
<models 1-2> декларативный же. Может пусть <models 10-30> выберет 30 и внутри сделать возможность задавать подмакросы для выборки частей из этой выборки (а может такое уже есть). Лишь бы внутренние if также работали.
А если это сложно впихивать, то может дать альтернативный внутренний api - сделать фасадный класс с методами выборки моделей из бд в переменную (а дальше уже по старинке ручками распихивать по хтмл). И дать возможность достучаться до этого фасада из шаблона (да хоть через $GLOBALS)
А тормозит из-за запроса. Лог долгих запросов показал что там есть запросы вида
Code: Select all
SELECT md.*, m.model_id as model_id, m.model_slug, m.model_name,
gi.url, gi.gallery_id,
rt.thumb_id, rt.height, rt.width, rt.thumb_url, rt.extra_thumb, rt.extra_thumb2, rt.extra_thumb3,
m.model_total_galleries, md.model_average_ctr
FROM rot_models as m
JOIN rot_models_data as md ON m.model_id = md.model_id and site_id = '1'
LEFT JOIN rot_gallery_info as gi on gi.url = m.model_id AND gi.gallery_type = 2 and gi.source_url = '1'
LEFT JOIN rot_thumbs AS rt ON rt.gallery_id = gi.gallery_id
WHERE 1 = 1
AND m.model_id IN (SELECT CAST(url as UNSIGNED) FROM rot_gallery_info WHERE gallery_type = 5)
AND m.model_total_galleries >= 1
ORDER BY md.model_average_ctr DESC
LIMIT 1000, 6
И вот такой выполняется аж 8 секунд. И если каждый $varN по 8 секунд....
Как я понимаю тут проблема ORDER BY ... OFFSET ... Чем больше смещение,тем больше тормозит. Предельное время - 14 секунд на запрос ибо данные просто заканчиваются.
В общем то даже если сделать возможность выбрать 1 раз, то все равно долго. Я погуглил варианты оптимизации и по примеру
https://habr.com/ru/articles/217521/ попробовал переписать так (если ничего не напутал - с SQL дело имею крайне редко)
Code: Select all
SELECT md.*, m.model_id as model_id, m.model_slug, m.model_name,
gi.url, gi.gallery_id,
rt.thumb_id, rt.height, rt.width, rt.thumb_url, rt.extra_thumb, rt.extra_thumb2, rt.extra_thumb3,
m.model_total_galleries, md.model_average_ctr
FROM rot_models as m
JOIN (SELECT m2.model_id AS mod_id
FROM rot_models AS m2
JOIN rot_models_data as md2 ON m2.model_id = md2.model_id and site_id = '1'
WHERE 1 = 1
AND m2.model_id IN (SELECT CAST(url as UNSIGNED) FROM rot_gallery_info WHERE gallery_type = 5)
AND m2.model_total_galleries >= 1
ORDER BY md2.model_average_ctr DESC
LIMIT 1000, 6) AS b ON b.mod_id = m.model_id
JOIN rot_models_data as md ON m.model_id = md.model_id and site_id = '1'
LEFT JOIN rot_gallery_info as gi on gi.url = m.model_id AND gi.gallery_type = 2 and gi.source_url = '1'
LEFT JOIN rot_thumbs AS rt ON rt.gallery_id = gi.gallery_id
И этот запрос выполняется за 0,062 сек
Правда получился не совсем эквивалент в выдаче. В оригинальном запросе смещение идет для результата JOIN (который имеет больше строк за счет LEFT JOIN rot_thumbs, которых может быть больше 1), но логически же результат валиден по идее. Ну может выдать больше 6 из-за 2+ gallery_id для одного model_id
Такое же наверное и с запросами для first_letter='A'
