Как ускорить поиск в 1С-Битрикс: полный гайд по индексации

Когда стандартный поиск в 1С-Битрикс начинает тормозить?

Встроенный поиск 1С-Битрикс использует таблицы b_search_content, b_search_content_stem, b_search_stem. На каталоге из 30 000 товаров полная переиндексация занимает 4–12 часов, агент CSearchIndex::IndexAgent крутится непрерывно, а качество поиска остаётся низким: стемминг не справляется с русской морфологией, релевантность не учитывает продажи. Наш опыт показывает, что грамотная настройка сокращает время индексации на 50–80% и повышает точность выдачи на 30–40%. Мы работаем с Битрикс более 10 лет и гарантируем результат. Проблема усугубляется, если на сайте одновременно активны несколько модулей — каждый лишний модуль добавляет 15–20% объёма индексных таблиц. Типичная картина: администратор включает поиск по форумам, блогам и документам, хотя пользователям нужен только каталог товаров. В результате индекс раздувается, запросы замедляются, а агент не успевает обрабатывать изменения.

Диагностика текущей индексации

Первым делом смотрим состояние индексных таблиц:

SELECT
    table_name,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
  AND table_name LIKE 'b_search%'
ORDER BY data_length DESC;

Таблица b_search_content_stem на крупном портале может занимать 2–5 ГБ. OPTIMIZE TABLE для неё блокирует запросы на часы — делаем только в техническое окно.

Как настроить параметры индексации?

В административном интерфейсе (Настройки → Поиск → Настройки) меняем ключевые параметры:

1. Минимальная длина слова — увеличиваем с 2 до 3–4. Двухбуквенные слова засоряют индекс и не несут поискового смысла.
2. Стоп-слова — добавляем предлоги, союзы, артикли. Для русскоязычного сайта базовый список включает 50–80 слов.
3. Индексируемые модули — отключаем модули, поиск по которым не нужен пользователям (форумы, блоги, документооборот).
4. Количество элементов за один проход агента — оптимально 50–100.

// В настройках модуля поиска или через агент
CSearch::ReIndex($moduleId, $start, $finish, $step = 50);

Инкрементальная vs полная индексация

Полная переиндексация (ReIndexAll) — только при первичной настройке или после серьёзных изменений структуры каталога. В рабочем режиме должна работать инкрементальная индексация через агент. Проблема: агент CSearchIndex::IndexAgent срабатывает на любое изменение DATE_CHANGE. При синхронизации с 1С дата меняется даже если контент не изменился — агент фактически переиндексирует весь каталог каждый раз. Решение: сравниваем хеш значимых полей до и после обновления. Обновляем DATE_CHANGE только при реальном изменении:

$oldHash = md5($oldElement['NAME'] . $oldElement['DETAIL_TEXT'] . implode(',', $oldProperties));
$newHash = md5($newElement['NAME'] . $newElement['DETAIL_TEXT'] . implode(',', $newProperties));

if ($oldHash !== $newHash) {
    // Обновляем с изменением DATE_CHANGE
} else {
    // Обновляем остатки/цены без триггера переиндексации
    $DB->Query("UPDATE b_iblock_element SET TIMESTAMP_X = TIMESTAMP_X WHERE ID = {$id}");
}

MySQL FULLTEXT vs Elasticsearch: что выбрать?

Если каталог до 30 000 позиций и нужен простой поиск — достаточно оптимизации FULLTEXT. Для 50 000+ и сложных фильтров лучше Elasticsearch.

Чистка устаревших записей индекса

На живых сайтах в b_search_content накапливаются записи удалённых элементов. Чистим пакетами по 1000 записей через агент или cron — одним DELETE на 100 000 в прод не работаем:

-- Найти записи удалённых элементов инфоблока
SELECT sc.ID, sc.PARAM1, sc.PARAM2
FROM b_search_content sc
LEFT JOIN b_iblock_element ie ON ie.ID = CAST(sc.PARAM1 AS UNSIGNED)
WHERE sc.MODULE_ID = 'iblock'
  AND ie.ID IS NULL
LIMIT 10000;

Что входит в оптимизацию поиска?

• Диагностика текущих индексов и настроек модуля поиска
• Настройка стоп-слов, минимальной длины слова, исключение лишних модулей
• Оптимизация агента инкрементальной индексации (хеширование полей)
• Настройка MySQL FULLTEXT (my.cnf: innodb_ft_min_token_size, стоп-таблица)
• Чистка мусора в индексах
• Мониторинг нулевых запросов (b_search_log)
• Документация по рекомендациям и регламенту поддержки

Мониторинг качества поиска

После оптимизации настраиваем логирование запросов с нулевой выдачей. Запросы с нулевой выдачей — сигнал к расширению контента или переходу на Elasticsearch.

Кейс: сокращение времени индексации в 4 раза

Клиент — интернет-магазин автозапчастей (40 000 товаров). Полная индексация длилась 8 часов, агент держал нагрузку CPU 70–90%. После настройки инкрементальной индексации с хешированием и оптимизации FULLTEXT время полного обхода сократилось до 2 часов, нагрузка CPU — до 15–20%. Качество поиска улучшилось: количество нулевых запросов снизилось на 35%. Экономия бюджета на облачные ресурсы составила около 400 000 ₽ в год.

Типичные ошибки при настройке поиска

• Установка минимальной длины слова = 1: индекс забивается мусором, поиск замедляется.
• Полная переиндексация каждую ночь: излишняя нагрузка, достаточно инкрементальной.
• Игнорирование стоп-слов: поиск находит статьи с предлогами вместо нужных товаров.
• Отсутствие мониторинга: нулевые запросы остаются незамеченными, контент не дополняется.

Результат

Оптимизация параметров и стратегии индексирования сокращает время полного обхода на 50–80%, снижает нагрузку агента до фонового уровня и улучшает релевантность выдачи. Свяжитесь с нами, чтобы получить консультацию и план работ. Закажите аудит поиска — оценим ваш проект за 1 день.