Профессиональная настройка индексов базы данных 1С-Битрикс

Мы нередко видим проекты, где запрос к каталогу на 50 000 товаров выполняется 4 секунды вместо 40 миллисекунд. EXPLAIN показывает ALL вместо ref — таблица читается целиком. Это классический симптом: индексы не добавлялись после роста данных или были случайно удалены при обновлении схемы. Подробнее о важности индексов можно прочитать в статье на Wikipedia. За 10 лет работы мы научились выявлять такие проблемы за минуты и устранять их с гарантией результата.

Проблема усугубляется тем, что Битрикс использует сложную схему с инфоблоками, где данные размазаны по десяткам таблиц. Без правильных индексов даже простой фильтр по свойствам превращается в полный перебор миллионов строк. Мы видим это на каждом втором проекте: сайт работал нормально до 10 000 товаров, а после 50 000 начал тормозить. Владельцы часто пытаются решить проблему кэшированием или апгрейдом сервера, но корень — в отсутствии индексов.

Согласно официальной документации MySQL, правильно подобранные индексы могут ускорить выполнение запросов в 10–100 раз.

Какие индексы критичны для инфоблоков?

Структура хранения данных инфоблоков разбита на несколько таблиц. Ниже — основные с рекомендуемыми индексами:

На боевом проекте b_iblock_element_property легко достигает 10–30 миллионов строк. Запрос фильтрации по двум свойствам без индекса — это full scan обеих таблиц, что сразу даёт секундные задержки.

Как диагностировать медленные запросы?

Первым делом включаем slow query log в MySQL/MariaDB:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Параллельно используем профилирование Битрикс через константы в dbconn.php:

define("DBDebug", true);
define("DBDebugToFile", true);

Лог пишется в bitrix/modules/main/tools/bx_sql.log. На продакшне включаем ненадолго — файл разрастается мгновенно. Анализируем топ-10 самых медленных запросов и смотрим их план через EXPLAIN.

Как мы добавляем недостающие индексы?

Проверяем наличие индексов через:

SHOW INDEX FROM b_iblock_element;
SHOW INDEX FROM b_iblock_element_property;

Добавляем все необходимые индексы одним батчем:

ALTER TABLE b_iblock_element
  ADD INDEX ix_ie_iblock_active_date (IBLOCK_ID, ACTIVE, DATE_ACTIVE_FROM);

ALTER TABLE b_iblock_element_property
  ADD INDEX ix_iep_iblock_prop_val (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE),
  ADD INDEX ix_iep_element_prop (IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID);

ALTER TABLE b_catalog_price
  ADD INDEX ix_cp_catalog_price (CATALOG_GROUP_ID, PRICE, CURRENCY);

ALTER TABLE b_catalog_store_product
  ADD INDEX ix_csp_product_store (PRODUCT_ID, STORE_ID);

ALTER TABLE b_stat_phrase_date
  ADD INDEX ix_spd_date_phrase (DATE1, PHRASE_ID);

Все изменения выполняем через pt-online-schema-change на таблицах >1 ГБ, чтобы избежать блокировок.

Почему кэширование не решает проблему?

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

Обслуживание индексов критично для производительности

Битрикс-сайты с модулем statistic накапливают миллионы строк в b_stat_* таблицах. После массовых удалений через административную панель индексы фрагментируются, а статистика распределения данных устаревает. Анализируем фрагментацию:

SELECT TABLE_NAME,
       ROUND(DATA_FREE/1024/1024, 2) AS free_mb,
       ROUND(DATA_LENGTH/1024/1024, 2) AS data_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'bitrix_db'
  AND DATA_FREE > 10485760
ORDER BY DATA_FREE DESC;

При фрагментации >20% данных выполняем OPTIMIZE TABLE (на InnoDB — полная перестройка) или используем pt-online-schema-change для онлайн-режима.

Типичные симптомы и решения

Что входит в нашу работу?

• Аудит текущих индексов и планов запросов — находим узкие места.
• Добавление и оптимизация индексов — под ключ, с тестированием на нагрузке.
• Автоматизация обслуживания — настраиваем агент ANALYZE TABLE еженедельно.
• Документация — фиксируем все изменения, схему индексов и рекомендации.
• Постпроектное сопровождение — отвечаем на вопросы, при необходимости корректируем.

Мы гарантируем, что после нашей настройки время выполнения типовых запросов сократится в 10–100 раз. Подтверждаем это результатами тестов до и после. Например, на одном проекте с каталогом на 200 000 товаров удалось снизить время загрузки главной с 8 секунд до 0.2 секунды — это в 40 раз быстрее, чем любая оптимизация кэширования. Экономия на серверных мощностях составила около 150 000 рублей в месяц, а стоимость аренды сервера уменьшилась на 40%.

Сроки и стоимость

Ориентировочные сроки работ — от 2 до 5 рабочих дней в зависимости от объёма данных и сложности схемы. Стоимость рассчитывается индивидуально после аудита. Мы открыто называем цену до начала работ и не скрываем дополнительных опций.

Закажите аудит индексов — выявим узкие места за один день. Получите консультацию: мы бесплатно оценим ваш проект. Опыт 10+ лет и 50+ проектов по оптимизации БД говорят сами за себя.

Дополнительно вы можете изучить официальную документацию MySQL по индексам для углублённого понимания.