Професійне налаштування індексів бази даних 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 по індексам для поглибленого розуміння.