для свойства товара. и по этому справочнику у меня фильтр работает довольно долго. секунды. в справочнике 863 элемента. если заменить этот справочник на обычные разделы каталога (распихать товары в разделы) это работает быстрее.
может я что-то не так делаю с фильтром и HL-справочником? или это нормально что он сортирует каталог в течении ~3-4 секунд а по разделам почти мгновенно? Или это нормальное поведение? товаров 125 тысяч
Подумай насчёт построения индекса для полей mysql-запроса, который используется фильтром. У меня, в похожей ситуации после построения индексов по двум столбцам удалось сократить время запроса с 1.5 минуты до времени менее секунды.
А что тут смущает? Это обычная таблица бд.
Смущает что это не делается автоматически, и я нигде не читал о таких методах. Это мне и фильтр дорабатывать надо чтобы он из этой таблицы данные брал?
если используете HL и все работает, только долго, то ничего дорабатывать не надо. Элементы инфоблока уже в своей таблице содержат поле IBLOCK_SECTION_ID, поэтому выборка происходит значительно быстрее, чем с отдельного доп свойства с привязкой к HL а там еще смотря какое поле в HL автоматом. методов конкретно на справочники я не видел, но в HL можно реализовать разную структуру и оптимальный метод не подберешь. Добавить индекс это не долго, и не требует каких-то сверх знаний, и не является чем-то сверхъестественным, обычный рабочий момент, который позволит бд быстрее обрабатывать выборку по этой таблице и фактически не имеет прямого отношения к логике бэка, т.е. в вашем случае к логике работы фильтра
Да. Смотрим код, какие поля задействованы, а потом через alter ... add index
Не подскажите пример, на какие столбцы сделали индексы?
У меня был hl-инфоблок с кастомным полями. Был прямой sql-запрос, сложная выборка с подзапросами по своим полям, поэтому, не зная, какие у вас столбцы в hl-инфоблоке, я ответить на ваш вопрос не могу.
Я думао разговор не про HL блок
Обсуждают сегодня