Медленные запросы

[vasuanin 0]

Добрый день!
Идет большая нагрзука на сервер http://prntscr.com/l8kzl5
Предполгаю что это из-за длинных запросов.
Логи прилагю
Цели:
1.Понять нагрузка из-за длинных запросов
2.Почему стали происходить длинные запросы (ранее не было)
3.Что нужно сделать что бы вылечить текущую проблему и избежать далее нагрузок.

mysql-slow_(4).zip

[YulanaKiev 5]

Привет, открой консоль разработчика в браузере загрузи страницу и повремени загрузки элементов все увидишь.

 

 

[chukcha 1 500]

1 час назад, YulanaKiev сказал:

Привет, открой консоль разработчика в браузере загрузи страницу и повремени загрузки элементов все увидишь.

 

 

А причем здесь это к медленным запросам?

то что там order by LCACE(p.product_id)

я промолчу.

[100napb 25]

весь лог не перелопатил, но в нем встречаются в осномном два тяжелых запроса.

Один типовой из стандартного метода опенкарта (getProducts из catalog\model\catalog\product.php):

Spoiler

SELECT
  p.product_id,
  (SELECT
      AVG(rating) AS total
    FROM oc_review r1
    WHERE r1.product_id = p.product_id
    AND r1.status = '1'
    GROUP BY r1.product_id) AS rating,
  (SELECT
      price
    FROM oc_product_discount pd2
    WHERE pd2.product_id = p.product_id
    AND pd2.customer_group_id = '1'
    AND pd2.quantity = '1'
    AND ((pd2.date_start = '0000-00-00'
    OR pd2.date_start < NOW())
    AND (pd2.date_end = '0000-00-00'
    OR pd2.date_end > NOW()))
    ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount,
  (SELECT
      price
    FROM oc_product_special ps
    WHERE ps.product_id = p.product_id
    AND ps.customer_group_id = '1'
    AND ((ps.date_start = '0000-00-00'
    OR ps.date_start < NOW())
    AND (ps.date_end = '0000-00-00'
    OR ps.date_end > NOW()))
    ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special
FROM oc_category_path cp
  LEFT JOIN oc_product_to_category p2c
    ON (cp.category_id = p2c.category_id)
  LEFT JOIN oc_product p
    ON (p2c.product_id = p.product_id)
  LEFT JOIN oc_product_description pd
    ON (p.product_id = pd.product_id)
  LEFT JOIN oc_product_to_store p2s
    ON (p.product_id = p2s.product_id)
WHERE pd.language_id = '1'
AND p.status = '1'
AND p.date_available <= NOW()
AND p2s.store_id = '0'
AND cp.path_id = '2247'
AND LCASE(pd.name) LIKE '%Смеситель%'
AND LCASE(pd.name) LIKE '%для%'
GROUP BY p.product_id
ORDER BY LCASE(p.product_id) DESC, LCASE(pd.name) DESC LIMIT 0, 4;

но время выполнения просто невменяемое - местами более 15 сек о_О. Это при каждом открытии карточки товара такое.

 

а еще есть какой-то фильтр, который генерит безумные запросы со временем выполнения до 20сек, типа

Spoiler

SELECT
  COUNT(DISTINCT p.product_id) AS total,
  fpa.attribute_id,
  fpa.attribute_group_id,
  fpa.attribute_value_mod
FROM oc_oct_filter_product_attribute fpa
  INNER JOIN oc_product p USING (product_id)
WHERE fpa.product_id IN (84235, 84232, .. over9000 записей)
GROUP BY fpa.attribute_value_mod;

 

Налицо отсутствие оптимизации БД. Судя по всему, у Вас достаточно много товаров, а Mysql, поди, работает на дефолтовых конфигах

 

19 hours ago, vasuanin said:

1.Понять нагрузка из-за длинных запросов
2.Почему стали происходить длинные запросы (ранее не было)
3.Что нужно сделать что бы вылечить текущую проблему и избежать далее нагрузок.

1. Их всего несколько. Но запросы "типовые".

2. Их медленное выполнение может быть связано с целым рядом причин: отсутствие индексов, сильная фрагментация таблиц, резкое увеличение объема данных (импорт нескольких тысяч товаров или подобное). Точно сказать сложно без анамнеза.

3. Возможно, стоит поискать специалиста, который сначала займется настройкой сервера mysql. А затем, по результатам, решить - стоит ли оптимизировать сами запросы.

 

Могу взяться посмотреть\исправить. Мне интересно - скучаю иногда по "старой" работе (за плечами несколько лет корпоративной работы в должности админа баз данных). Пишите в ЛС, если что.

Изменено 22 октября, 2018 пользователем 100napb

[markimax 2 054]

29 минут назад, 100napb сказал:

весь лог не перелопатил, но в нем встречаются в осномном два тяжелых запроса.

Один типовой из стандартного метода опенкарта (getProducts из catalog\model\catalog\product.php):

  Показать контент

SELECT
  p.product_id,
  (SELECT
      AVG(rating) AS total
    FROM oc_review r1
    WHERE r1.product_id = p.product_id
    AND r1.status = '1'
    GROUP BY r1.product_id) AS rating,
  (SELECT
      price
    FROM oc_product_discount pd2
    WHERE pd2.product_id = p.product_id
    AND pd2.customer_group_id = '1'
    AND pd2.quantity = '1'
    AND ((pd2.date_start = '0000-00-00'
    OR pd2.date_start < NOW())
    AND (pd2.date_end = '0000-00-00'
    OR pd2.date_end > NOW()))
    ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount,
  (SELECT
      price
    FROM oc_product_special ps
    WHERE ps.product_id = p.product_id
    AND ps.customer_group_id = '1'
    AND ((ps.date_start = '0000-00-00'
    OR ps.date_start < NOW())
    AND (ps.date_end = '0000-00-00'
    OR ps.date_end > NOW()))
    ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special
FROM oc_category_path cp
  LEFT JOIN oc_product_to_category p2c
    ON (cp.category_id = p2c.category_id)
  LEFT JOIN oc_product p
    ON (p2c.product_id = p.product_id)
  LEFT JOIN oc_product_description pd
    ON (p.product_id = pd.product_id)
  LEFT JOIN oc_product_to_store p2s
    ON (p.product_id = p2s.product_id)
WHERE pd.language_id = '1'
AND p.status = '1'
AND p.date_available <= NOW()
AND p2s.store_id = '0'
AND cp.path_id = '2247'
AND LCASE(pd.name) LIKE '%Смеситель%'
AND LCASE(pd.name) LIKE '%для%'
GROUP BY p.product_id
ORDER BY LCASE(p.product_id) DESC, LCASE(pd.name) DESC LIMIT 0, 4;

но время выполнения просто невменяемое - местами более 15 сек о_О. Это при каждом открытии карточки товара такое.

 

 

Это не запрос, это просто треш какой то
Like '%....%' делает перебор по всей базе не используя индексы
Никакая "оптимизация" настроек MySQL не поможет с этим запросом
 

[100napb 25]

39 minutes ago, markimax said:

Это не запрос, это просто треш какой то
Like '%....%' делает перебор по всей базе не используя индексы
Никакая "оптимизация" настроек MySQL не поможет с этим запросом
 

 

 ¯\_(ツ)_/¯

в OC много подобного "из коробки" и Вы это лучше меня знаете)) ни я, ни топикстартер не виноват в том, что этот монструозный запрос кто-то родил на свет )) а так... можно переписать, можно полнотекстовый индекс попробовать добавить, можно... не патовая ситуация, одним словом

Изменено 22 октября, 2018 пользователем 100napb