Счётчик товаров в категории

[Prooksius]

Как-то пришлось работать с магазином, в котором было много товаров, до 50к. И заказчик очень захотел, чтобы показывались количества товаров в разных категориях. В модуле category они обычно выводятся в скобочках. И есть возможность отключать это в Системе настройкой "Счётчик товаров в категории". Там еще предупреждение выводится, что если много товаров - будет тормозить.

Проанализировал запрос, который делается при подсчете количества товаров в папке, phpMyAdmin (анализ запроса). Выяснилось, что он очень нерационально выполняется. Явно было недостаточно какого-то индекса. И точно, в таблице oc_category_path нехватало простого индекса по полю path_id. Там есть Primary по двум полям, но нужно было именно по path_id.
Добавьте, у кого много товаров и тормозит. Мне помогло существенно.

Змінено 26 листопада 2020 користувачем Prooksius

[spectre]

а не проще ночью по крону считать и складывать в какое-то поле в таблице category чтоб сервер не колбасить?

 

[Prooksius]

я еще прикрутил кэш к этому делу.
То есть, если считается для какой-то категории (только для нее, без учета всяких фильтров) тогда смотрим в кэш для этой категории, если есть - то не обращаемся к БД и берем из кэша. Если сохраненного в кэше по этой категории нет - делаем стандартный запрос к БД и сохраняем в кэш для этой категории.

Я говорю о станартном кэше опенкарта:
$this->cache->get
$this->cache->set

Но вот если надо почитать количество с учетом каких-то проставленных фильтров - вариантов может быть очень много, все не сохранишь, будь то в кэше, будь то в каком-то поле...

[chukcha]

Только что, spectre сказал:

а не проще ночью по крону считать и складывать в какое-то поле в таблице category чтоб сервер не колбасить?

 

проще, если частое обновление - то и чаще

 

И.. Это если включен
'filter_sub_category' => true

[chukcha]

1 минуту назад, Prooksius сказал:

Если сохраненного в кэше по этой категории нет - делаем стандартный запрос к БД и сохраняем в кэш для этой категории.

Тут все зависит от частоты посещения категории

Если категорий мало, а посещений много - то, возможно кеш и поможет.
А если категорий много , и есть мало посещаемые, то такой кеш до одного места..

[Prooksius]

Но в том, то и дело, что этот доп. индекс у меня решил все проблемы со скоростью. Собствено уже и кэш не нужен, все быстро открывается

[almir]

1 минуту назад, Prooksius сказал:

Но в том, то и дело, что этот доп. индекс у меня решил все проблемы со скоростью. Собствено уже и кэш не нужен, все быстро открывается

 

Prooksius не подскажите с примером как поставить такой индекс)

[Prooksius]

3 минуты назад, almir сказал:

 

Prooksius не подскажите с примером как поставить такой индекс)

https://www.awesomescreenshot.com/video/1860545?key=55b877a3edb55b1294bf1562932d0a0a

[almir]

2 минуты назад, Prooksius сказал:

https://www.awesomescreenshot.com/video/1860545?key=55b877a3edb55b1294bf1562932d0a0a

 

+

[chukcha]

ALTER TABLE `oc_category_path` ADD INDEX (`path_id`);

 

[Prooksius]

2 минуты назад, chukcha сказал:

ALTER TABLE `oc_category_path` ADD INDEX (`category_id`);

 

только не category_id, а path_id

[chukcha]

5 минут назад, Prooksius сказал:

только не category_id, а path_id

поправил, писал с листа

[chukcha]

А также сделал explain - рекомендую и вам

 

https://prnt.sc/vqhcd4

 

Но

 

https://prnt.sc/vqhd5x

 

И еще одно но

сравните с первым скрином

https://prnt.sc/vqhg7x

 

 

т.е.. ваш случай частичный

[Prooksius]

ну да, вот у меня как раз было подобным первому скрину без того индекса, а на втором - уже с ним.

[chukcha]

Только что, Prooksius сказал:

ну да, вот у меня как раз было подобным первому скрину без того индекса, а на втором - уже с ним.

И заметьте все запросы делались с наличием индекса по path_id

[Prooksius]

аа, вот оно что, в каких-то случаях он все-таки не используется.. Ясно.

[100napb]

5 minutes ago, Prooksius said:

аа, вот оно что, в каких-то случаях он все-таки не используется.. Ясно.

например в тех случаях, когда оптимизатор mysql решает, что фулскан таблицы ему будет быстрее сделать, чем выбрать даже используя индекс какое-то довольно большое (например, больше половины всех товаров) количество товаров из какой-то жирной категории.

 

индекс по path_id - мастхэв для мелких категорий, все верно 👍

Змінено 26 листопада 2020 користувачем 100napb

[vier]

так же для Оптимизации подсчета Количества товара в запросе не нужна таблица `product_description` и соответственно условие по Языку - `language_id`

и если вместо NOW() можно использовать функцию из php date("Y-m-d") , то запрос сам собой будет кешироваться.

но это код Опенкарта надо менять.

[chukcha]

1 минуту назад, vier сказал:

Количества товара в запросе не нужна таблица `product_description` и соответственно условие по Языку - `language_id`

Не поверите... нужна!!!

Существуют такие ситуации, что в базе нет соответствующих языковых сущностей

[vier]

3 минуты назад, chukcha сказал:

Существуют такие ситуации, что в базе нет соответствующих языковых сущностей

ааа, я понял - это тот случай...

[Prooksius]

20 минут назад, chukcha сказал:

Не поверите... нужна!!!

Существуют такие ситуации, что в базе нет соответствующих языковых сущностей

Блин, не учел этот момент, Действительно такое бывает, но это, по-моему, скорее ошибка, нежели нормальная работа магазина.
А я действительно, как vier и сказал, убрал эту таблицу, если это не поиск по названию, например, а просто подсчет кол-ва товаров, например, в категории.

[chukcha]

4 минуты назад, Prooksius сказал:

Действительно такое бывает, но это, по-моему, скорее ошибка, нежели нормальная работа магазина.

Это фича

Конечно, это очень маленький процент

Например была задача..
Не показывать товар, который не имеет перевод контента.