Сайт стал очень долго открываться

[markimax]

тут ты сам себе противоречишь - с одной стороны Opencart сделал не правильно , всё в нем не так, всё надо переписать, но сам же используешь полные копии запросов

 

Оптимизировал, взял копии (ну почти :) )  и соединил их Union вместо OR

 

При использовании OR - при большом количестве товаров и категорий - индексы бы не использовались, все шло методом перебора. При использовании union - индексы используются

 

Мне вот интересно как себе ты представляешь вот это:

не добавлять новые UNION если уже достигнут лимит

 

 

Как ты определишь, что достигнут предел, а вдруг в последней категории как раз находиться отзыв который лучше подходит по условиям (новее например)  ;)

[markimax]

Я бы наверно сделал вместо UNION запросов с разными WHERE c.category_id = '...', сделал бы один запрос с

WHERE c.category_id IN('id1', 'id2',...) а потом бы результаты отсортировал\сгруппировал по категориям.

 

Когда много категорий IN работает как OR - т.е. забудьте про использование индексов

 

т.е.WHERE c.category_id IN ('id1', 'id2',...n) будет тоже самое что WHERE c.category_id='id1' OR c.category_id='id2'  .... OR c.category_id=n

 

Поэтому лучше использовать много простых запросов с использованием индексов чем один большой без использования, так как он на большом количестве товаров просто положит mysql сервер

 

IN отлично работает, только когда мало категорий в множестве и мало товаров, тогда mysql еще может найти вариант как использовать индексы, только в IN более 3-4 "категорий" и в базе не 10 товаров, а гораздо больше - все, забудьте про индексы.

 

Вот EXPLAIN

 

EXPLAIN  SELECT *
FROM `category`
WHERE category_id
IN ( 18, 20, 25, 26, 27, 28, 29, 30 ) 
 

 

 

id select_type table type possible_keys key key_len ref rows Extra 1

SIMPLE category ALL PRIMARY NULL NULL NULL 16 Using where

 

А когда в БД (когда еще LJ товаров пойдет) ref rows = 10`000 - считайте что mysql у вас загнулся

[markimax]

Не индексами едиными... Еще есть кэш MySQL, который неплохо помогает при одинаковых запросах

 

Еще давайте поглядим на кусок запроса между юнионами

тоже можно убрать. По рейтингу сортировки вроде как нет (как в товарах), а рейтинг вычислить можно уже после того, как записи будут отрезаны LIMIT'ом. В итоге мы получим подзапросы не для всех 1000 товара, а только для LIMIT.

Аналогично с JOINами по которым нет явной сортировки или поиска: category_description, product_description

 

Да, у UNION одинаковые запросы и кеш mysql будет работать.

 

Насчет рейтинга - тут вы правы (точнее уже нет, смотрим P.S.), надо потом сделать вычисление. А вот с LJ не получиться, там только один LJ для "статистики" (описание категории), остальные все "работают".

 

P.S. Есть сортировка по рейтингу :(

 

Змінено 21 травня 2013 користувачем markimax

[markimax]

Знаете я (доверяй, но проверяй) все же провел эксперимент с IN (и создал метод на IN) - да запрос получился маленький, но скорость выполнения даже на 2 категориях уступает "длинному" UNION, все же кеш mysql на одинаковых запросах работает быстро

 

 

(SELECT DISTINCT cd.name AS blog_name,
rd.name AS record_name,
comm.*,
comm.date_added AS date_available,
comm.comment_id AS commentid,
rec.viewed AS record_viewed,
comm.rating AS rating,
c.blog_id,
rec.image,

(SELECT AVG(rating) AS total
FROM roc_comment r1
WHERE r1.record_id = rec.record_id
AND r1.status = '1'
GROUP BY r1.record_id) AS rating_avg,

(SELECT COUNT(*) AS total
FROM roc_comment r2
WHERE r2.record_id = rec.record_id
AND r2.status = '1'
GROUP BY r2.record_id) AS record_comments,
'blogs' AS TYPE
FROM roc_blog c
LEFT JOIN roc_blog_description cd ON (c.blog_id = cd.blog_id)
LEFT JOIN roc_blog_to_store c2s ON (c.blog_id = c2s.blog_id)
LEFT JOIN roc_record_to_blog r2b ON (c.blog_id = r2b.blog_id)
LEFT JOIN roc_record rec ON (rec.record_id = r2b.record_id)
LEFT JOIN roc_record_to_store r2s ON (r2s.record_id = rec.record_id)
LEFT JOIN roc_record_description rd ON (rec.record_id = rd.record_id)
LEFT JOIN roc_comment comm ON (rec.record_id = comm.record_id)
WHERE cd.language_id = '1'
AND rd.language_id = '1'
AND c2s.store_id = '0'
AND r2s.store_id = '0'
AND c.status = '1'
AND rec.status = '1'
AND comm.status = '1'
AND c.blog_id IN (1, 2, 3)
AND c.customer_group_id = '1')
UNION
(SELECT DISTINCT cd.name AS blog_name,
rd.name AS record_name,
comm.*,
comm.date_added AS date_available,
comm.review_id AS commentid,
rec.viewed AS record_viewed,
comm.rating AS rating,
c.category_id AS blog_id,
rec.image,

(SELECT AVG(rating) AS total
FROM roc_review r1
WHERE r1.product_id = rec.product_id
AND r1.status = '1'
GROUP BY r1.product_id) AS rating_avg,

(SELECT COUNT(*) AS total
FROM roc_review r2
WHERE r2.product_id = rec.product_id
AND r2.status = '1'
GROUP BY r2.product_id) AS record_comments,
'categories' AS TYPE
FROM roc_category c
LEFT JOIN roc_category_description cd ON (c.category_id = cd.category_id)
LEFT JOIN roc_category_to_store c2s ON (c.category_id = c2s.category_id)
LEFT JOIN roc_product_to_category r2b ON (c.category_id = r2b.category_id)
LEFT JOIN roc_product rec ON (rec.product_id = r2b.product_id)
LEFT JOIN roc_product_to_store r2s ON (r2s.product_id = rec.product_id)
LEFT JOIN roc_product_description rd ON (rec.product_id = rd.product_id)
LEFT JOIN roc_review comm ON (rec.product_id = comm.product_id)
WHERE cd.language_id = '1'
AND rd.language_id = '1'
AND c2s.store_id = '0'
AND r2s.store_id = '0'
AND c.status = '1'
AND rec.status = '1'
AND comm.status = '1'
AND c.category_id IN (59 , 20, 32, 35))
ORDER BY date_available DESC LIMIT 0,4
 

Красивее? Да, но работает медленнее, чем на UNION

[dinox]

По поводу перенаправления на myopencart.net вот причина https://opencartforum.com/topic/22202-proverka-na-nalichie-vredonosnogo-koda-na-vashikh/

[sekretdostatka]

Ребята помогите !

 

Внезапно очень медленно стала грузиться именно Главная страница сайта https://moroshka.com.ua/  Все остальные летают. Но вот только переходишь на Главную и всё. Грузится очень долго.

Хотя техподдержка хостинга написала, что код главной страницы генерируется за 0.2 секунду, что является достаточно хорошим показателем. Но по факту Главная грузится очень долго

 

Сделано на ocStore 2.1.0.2

Змінено 14 червня 2017 користувачем sekretdostatka

[snastik]

6 минут назад, sekretdostatka сказал:

Ребята помогите !

 

Внезапно очень медленно стала грузиться именно Главная страница сайта https://moroshka.com.ua/  Все остальные летают. Но вот только переходишь на Главную и всё. Грузится очень долго.

Хотя техподдержка хостинга написала, что код главной страницы генерируется за 0.2 секунду, что является достаточно хорошим показателем. Но по факту Главная грузится очень долго

 

Сделано на ocStore 2.1.0.2

Убирайте все внешние скрипты по очереди и проверяйте

в частности bitrix24, антивирус и все остальное.

С Украины действительно тупит, через VPN - никаких проблем.

[Shureg]

в России нормально открывается, быстро. Если на Украине медленно - смотрите, где у вас там вконтакты, яндексы и пр.

[ocdev_pro]

У сайта виджет Вконтакте где-то висит openapi.js не грузится из-за блокировки

[sekretdostatka]

Спасибо ребята. Главная уже летает. Стоял скрытый виджет группы Vk