Скорость выполнения запросов Mysql
Вопрос наверное немного не в тему но тем не менее:
SELECT DISTINCT
pf3.feature_id,
pf3.feature_value_id
FROM
shop_product p
JOIN shop_product_features pf1 ON p.id = pf1.product_id AND pf1.feature_id = 122 AND pf1.feature_value_id IN(20219)
JOIN shop_product_features pf2 ON p.id = pf2.product_id AND pf2.feature_id = 120 AND pf2.feature_value_id IN(21766)
JOIN shop_product_features pf3 ON p.id = pf3.product_id
WHERE
p.status = 1
AND p.price >= '2000'
Запрос выполняется 15 секунд, что на сервере NVMe дисками, что на локалке с SSD.
Это кусок запроса в категории с фильтром.
shop_product - 120 тыс записей shop_product_features - 2,5 миллиона записей
Что то можно сделать с этим или только уменьшать количество товара/характеристик?
14 ответов
Попробуйте выполнить рекомендации из этой темы - https://support.webasyst.ru/forum/44397/dlya-uskoreniya-mnozhestvennykh-dzhoynov---dobavit-dop-indeks-po-polyam-feature_value_id-sku_id-v-tablitse-shop_product_features/
Нет. Индекс абсолютно не помогает. Остальные настройки не для MyIsam.
У вас база MyIsam или вы ее конвертировали в InnoDB когда-то?
Можете скинуть для таблиц shop_product_features, product_id, feature_value_id и shop_product - какие индексы и по каким полям уже есть в базе?
ps: был в работе магазин с большим кол-вом товаров и с сопоставимым кол-вом значений хар-тик, как у вас. Там на обычных SSD даже все норм работало.
Вот вырезка из базы https://disk.yandex.ru/d/Fsti1...
~100,000 shop_product
~2,500,000 shop_product_features
и запрос оригинальный
SELECT DISTINCT pf3.feature_id, pf3.feature_value_id FROM shop_product p JOIN shop_product_features pf1 ON p.id = pf1.product_id JOIN shop_product_features pf2 ON p.id = pf2.product_id JOIN shop_product_features pf3 ON p.id = pf3.product_id WHERE p.status = 1 AND p.status = 1 AND pf1.feature_id = 122 AND pf1.feature_value_id IN (20219) AND p.status = 1 AND p.price >= '2000' AND pf2.feature_id = 120 AND pf2.feature_value_id IN (21766);Проблема не в базе и не в индексах.
А в том, что запрос ваш отдает 25 тысяч строк в ответ.!!!
Какой плагин столько запрашивает за раз?
Надо сам код править скорее всего.
У вас какая версия shop-script стоит?
Может был какой-то баг и надо обновиться... или исправлять самому.
Вот категория с Золотыми кольцами, https://www.myjewels.ru/catego...
Если в ней включить фильтр по вставкам все сразу начинает умирать.
Я обманул чутка. Убрал из скрипта COUNT(*)
По факту выполняется
но все равно выполняется очень долго...
Интересно а разработчики не хотят прокомментировать данную тему?
Т.е. у вас категория "Золотые кольца" динамическая получается или это какой-то СЕО-фильтр по хар-кам?
Как на неё выйти из меню навигации сайта?
При беглом осмотре вывод пока только один - сегментируйте ваши товарные предложения более точечно по категориям. При базе 850+ тыс. товаров это просто необходимо делать.
Автоматическое управление товарами (плагин) позволит вам всё аккуратно разложить как надо и поддерживать наполнение, уменьшив охваты фильтров во фронтенде, сдвигая наиболее сложные в подкатегории глубже или вообще наполняя подкатегории автоматически по параметрам хар-к по cron.
Приведу пример.
Обведенное на скриншоте должно быть сделано подкатегориями, а не параметрами фильтра. Да и с размерным фильтром тоже какая-то жесть. Там часть параметров явно попутана по единицам измерения. Стандартный размерный шаг ювелирых колец - 0,5 мм. Изредка встречаются шаги 0,25.
Затем идем глубже и делим кольца из Золота на кольца со вставками и без (ну или ещё на какие-то типы колец), а уже там, где остаются со вставками, активируем фильтр по вставке и размеру, либо формируем сео-подкатегории с размерами с определенным шагом и т.п. Самые ходовые женские от 17 до 18, а у мужчин – от 19 до 20,5 можно оформить категориями по шагу 0,5. Ну и т.д.
Сейчас у вас всё в одной большой куче, которую вы хотите разбирать простыми фильтрами на самом верхнем уровне. Так это не работает.
Да у вас будет много подкатегорий. Но это даже и лучше, т.к. вы сможете продвигаться по целому кусту предложений и работать это всё будет в разы быстрее, будучи разобрано и рассортировано аккуратно.
replicant, Идея правильная, но как быть тогда с категорией Кольца, ведь она же все равно включает в себя все товары из подкатегорий? И опять получится фильтр по всем товарам.
Я почему это спрашиваю, у меня тоже есть большая категория с 44 000 товаров, но за счет настройки сервера, удалось сократить время ответа сервера до 250 мс. Но если воспользоваться вашим советом, можно сделать эту категорию значительно легче
Да пусть она включает хоть 1.5 млн товаров. Просто в ней вообще не должно быть фильтров (сама загрузка фильтров с построением условий уже проблема при загрузке категории) и товары там не должны быть видны, кроме м.б. горячих предложений в рамках нескольких десятков позиций на уровне локальных списков. Поднятие в неё товаров из категорий уровнем ниже должно быть выключено.
В толстой категории должны быть подкатегории с правильным позиционированием товаров, например по материалам как минимум, а лучше ещё точнее (то же золото со вставками и без уже должны быть в разных местах). Эти подкатегории уже сами по сути фильтры, уменьшающие первичные выборки в разы. Да и кол-во вариаций хар-к в них будет скромнее и мы не будем натыкаться на пустые значения комбинаций фильтров (см. скриншот ниже).
У вас слишком много товаров, чтобы разрулить всё фильтрами так легко и масса возможностей создать узкоспециализированные категории.
Вместо более хитрой и коммерчески эффективной игры с привлекательной подачей вы предпочитаете добавить закиси азота в движок, чтобы "тащил". Он потащит в итоге как-нибудь, но, если честно, то с такой подачей фильтра как сейчас выбирать что-то из такого кол-ва желание пропадает (там даже размеры как попало). Размеры должны быть самым глубоким фильтром по расположению по категориям от корня.
Приведу ещё один пример, чтобы было понятно.
Есть материал СТАЛЬ. Есть вставки из материала в фильтрах Колец, но сколько из них относится к Стали?
По логике при выборе материала я уже не должен видеть Агат, но ... ну вы меня поняли. И это ещё не включил опцию +размер.
Вы просто понижаете пользовательский опыт и переходы внутри сайта одной такой толстой категорией с фильтрами. Я не осилю эту выборку с позиции покупателя. Ощущение что потерялся, слишком много всего, акцентов нет и никак не смогу найти точно ничего, глаз не цепляется и всё ровным слоем. Где подсказки? Где наводки?
В идеале найти скрипт/код, который генерирует данный запрос.
Может стоит устаревший плагин или shop-script?
В статической категории при фильтрации по нескольким параметрам даже в такой большой категории - тормозов таких не должно быть.
Это же простая выборка - которая быстро проходится за счёт индексов!
Имхо, где-то есть баг/ошибка в коде плагина или самого фреймворка - надо искать.
MyIsam всегда вроде была
это с оригинальной базы. и индексы вроде оригинальные.
на тесте разные делал. не помогало.
А тип и версия mysql у вас какие? Да, товаров и характеристик много, но 15с это перебор, кмк.
Для этого и кинул вырезку из базы со скриптом. Что бы пробовали.
Я конечно каталог переформатирую по советам, но это не отменяет того что запросы непонятно долго выполняются.