Читал я тут обсуждение одного поста на Хабре, никакого отношения к CS-Cart не имеющей. Прочитал вот этот комментарий, и что-то прямо ёкнуло внутри…
Пожалуйста, примите меры. У нас такого тоже хватает, что напрямую влияет на производительность сайтов. Ну и туда же кучи каунтов, не очень то и нужных в запросах, замедляющих их радикально. На крохотных базах вроде демок всё ок, как только база разрастается, начинаются проблемы отовсюду. А править ядро из-за критичных проблем с производительностью - плохо, лишает возможности обновляться, с одной стороны, а с другой - лишает CS-Cart подписок на обновления.
Там этого хватает, на всё не укажешь - нужно системное решение, в виде какой-то выработанной методологии написания запросов и проверки их производительности. Ведь местами сложные напросы написаны быстрыми, а в других местах какие-то странные медленные решения. Простой пример - многие запросы с пересчетом всех строк в таблице, можно прямо по коду искать. Смысла большого не всегда имеют, но один и тот же запрос вместо тысячных долей секунд начинает выполняться несколько секунд. В итоге сайт падает. Если на сайте какой-никакой трафик, то множество запросов выполняющихся за 0.1-0.5 секунды уже создают очереди к БД и приводят к тормозам/падению сайта, пользователи начинают сталкиваться с невозможностью добавить товар в корзину, перейти на нужную страницу, оформить заказ.
Самое простое, что можно сделать - взять сайт с существенным числом товаров(в случае с MV это пара-тройка миллионов хотя бы, лучше десяток) и заказов, посмотреть сколько отрабатывают запросы открытия главной страницы админки. И иметь в виду, что пока всё это дело отрабатывает и тормозит - пользователи не могут открыть нужную страницу товаров или добавить товар в корзину. Т.е. это не проблема админки в действительности. А если над сайтом работает несколько человек(это не энтерпрайз всё-таки, когда есть пара контентщиков и пара менеджеров), то сколько раз за день они оказываются на главной…
Цены, названия товаров, статус товаров, привязка к категориям…всё это находится в разных таблицах.
Варианта 2, или джойнить таблицы в одном запросе, или делать выборку из каждой таблицы отдельным запросом. Не уверен что второй вариант лучше.
Count нужны для пагинации, так как нужно знать общее число строк по данным конкретным условиям.
Можно подточить запросы под конкретную установку с определенными размерами и используемым функционалом. Но часто то что полезно большой базе будет тормозить среднюю по размерам.
Ну вот по поводу уверенности: у меня был выбор, писать модуль “правильно”, то есть получать данные по заказам, товарам итд правильным путем, не обращаясь к БД а пользуясь функциями ядра. И это действительно правильно, потому что при изменении структуры базы после обновления работоспособность модуля сохранится.
Или второй путь - получать конкретные данные, в цикле обработать и на их основе получить недостающие. Даже если цикл в цикле будет несколько раз (аналог многочисленных джойнов). Результат - второй вариант работал на порядок (в десяток раз - поясняю) быстрее. Потому что в особых случаях сотни мегабайт данных, в которые превращаются мегабайтные таблицы при многократном соединении - надо еще и разместить в памяти и несколько раз перечитать.
Да, надо искать, пробовать, тестить. А на это ни у кого времени нет, потому что за это денег не платят.
