Надо смотреть что за запросы у тебя ходят. Агрегации не сильная сторона Mysql - с этой задачей куда лучше поисковые движки справляются типо elasticsearch

но тут не совсем поиск, здесь много фильтров прост(

может кто знает - есть ли альтернатива встроенному кэшу из мускула древнего? только для 8ки

Как насчет оптимизации запросов то

я индексами пытаюсь

elasticsearch очень хорошо умеет работать с формированием фильтров

Having a file template with blade.php as the extension doesn't show up in the new file dialog in the latest PHPStorm version. It used to work in all previous versions

плюс все лишнее убираю из самих запросов. суть в том, что они и должны быть сложными из-за особенности сайта((

Объясни суть своих запросов. И уточни количество данных примерное

а как насче проксей

тип такого

Это аля кеш на mysql при настройке

С бубном потанцевать и будет кэширование

пример самой популярной страницы:

в районе 5 проверок в хэдере более менее простых на наличие в базе элементов. дефолтные where('id', 1) например

далее показываем список итемов на странице. их в районе 800, пагинация по 20.

далее есть фильтр на странице, в него нужны каунты для проверки, есть ли в выведенном списке элементы с теми или иными характеристиками. 33 фильтра

чтобы получить каунт по каждому я беру lists('id') всех элементов списка, далее делаю запросы вида  whereIn('id', $lists)->where('param', 1)->get()->count(),  whereIn('id', $lists)->where('param2', 1)->get()->count() - к примеру. и так 33 раза. ибо как еще получить каунт для фильтра я хз. результаты этих каунтов я как в мемкеш и помещал

а бывает еще чтобы достать параметр нужно присобачить доп. таблицы, ибо в них инфа

Ну в принципе понятно. Так агрегации не строят.

альтернатива в данном случае? сайт на октбяре, это лара по сути та же просто с оболочкой

чет жостко, те ты делал n запросов а потом в коллекции на них каунт применял?)

можно же одним запросом все каунты собрать