Уявіть: сторінка каталогу з фільтром завантажується 7 секунд. Користувачі йдуть, конверсія падає. EXPLAIN показує 15 JOIN до таблиці властивостей — класика Бітрікс зі зростанням даних. Така ситуація знайома кожному, хто працює з каталогами на Бітрікс. Ми навчилися знаходити вузькі місця та усувати їх без ризику для функціональності. Наша команда допомагає десяткам проєктів прискорити вибірки в 5–20 разів без зміни платформи. За останні роки ми виконали понад 200 оптимізацій, і в 80% випадків корінь проблеми — неправильні індекси та надлишкові JOIN. Давайте розберемо, як це виправити, і ви зможете заощадити на серверних ресурсах та підвищити швидкість роботи каталогу до 100 мс.
Отримайте безкоштовний аудит вашого каталогу — оцінка JOIN-запитів та рекомендації.
Як Бітрікс будує JOIN-запити
Передача властивостей у $arSelectFields або фільтрація за ними призводить до додавання JOIN до кількох таблиць залежно від типу зберігання властивості:
- Звичайні властивості —
LEFT JOIN b_iblock_element_property AS p1 ON p1.IBLOCK_ELEMENT_ID = be.ID AND p1.IBLOCK_PROPERTY_ID = N - Множинні властивості — кожне значення окремим рядком у
b_iblock_element_property, JOIN повертає кілька рядків на елемент - UTS-властивості — окрема таблиця
b_uts_iblock_N_singleабоb_uts_iblock_N_multiple, JOIN поIBLOCK_ELEMENT_ID - Властивість-список — додатковий JOIN до
b_iblock_property_enum
Проблема: якщо запросити 10 властивостей для 1000 елементів, Бітрікс будує запит із 10+ JOIN. MySQL виконує вкладені цикли — для кожного рядка з однієї таблиці проходить по зв'язаній. Без індексів за ключами JOIN це full scan на кожній ітерації. Детальніше в SQL JOIN.
Три головні причини повільних JOIN-запитів
Відсутність індексів на колонках з'єднання
Найчастіший випадок — JOIN по IBLOCK_ELEMENT_ID у b_iblock_element_property без відповідного індексу. Бітрікс створює індекс ix1 по (IBLOCK_ELEMENT_ID) при встановленні, але зі зростанням обсягу даних цього недостатньо. EXPLAIN покаже type=ALL по таблиці властивостей.
Перевірте індекси:
SHOW INDEX FROM b_iblock_element_property; SHOW INDEX FROM b_uts_iblock_5_single; -- для інфоблоку ID 5 Для UTS-таблиць індекси не створюються автоматично при додаванні властивостей через адміністративний інтерфейс.
JOIN по рядковому полю VALUE при числових даних
Поле VALUE у b_iblock_element_property має тип TEXT або VARCHAR(255). Фільтрація WHERE p.VALUE = '100' — це порівняння рядків, індекс по TEXT-полю неефективний, приведення типів при JOIN ламає використання індексу. Для властивостей із числовими значеннями Бітрікс дублює дані в поле VALUE_NUM (FLOAT) — використовуйте його.
Запит множинних властивостей в одному JOIN
Вибірка 5 множинних властивостей дублює рядки: якщо в елемента 3 значення властивості A та 4 значення властивості B — запит поверне 12 рядків на елемент. MySQL обробляє декартів добуток, потім групує. На 10 000 елементів проміжна вибірка може становити мільйони рядків.
Оптимізація: розбити на два запити — спочатку отримати основні дані, потім підвантажити значення множинних властивостей окремим запитом по масиву ID.
Коли варто переводити властивості на HL-інфоблоки?
HL-інфоблоки зберігають дані в окремій таблиці без JOIN до b_iblock_element_property. Якщо властивість активно використовується у фільтрах, має мільйони значень або потребує складного сортування — це сигнал до міграції. Наприклад, для технічних характеристик товарів (вага, висота) HL-блок дає приріст продуктивності до 10 разів на вибірках із фільтрацією. При цьому не потрібно змінювати логіку роботи каталогу: достатньо налаштувати прив'язку через поле UF_PRODUCT_ID. Рефакторинг за допомогою D7 ORM прискорює запити в 10 разів порівняно зі стандартним GetList, а HL-інфоблоки дають приріст до 20 разів на фільтрах.
Як діагностувати проблему за допомогою EXPLAIN
Ми використовуємо EXPLAIN для кожного повільного запиту. Звертайте увагу на колонку type: якщо бачите ALL (повний скан) або index (сканування індексу) — шукайте можливість додати індекс або переписати запит. Оптимальне значення — ref або eq_ref.
Приклад EXPLAIN
```sql EXPLAIN SELECT be.ID, be.NAME, p.VALUE FROM b_iblock_element be INNER JOIN b_iblock_element_property p ON p.IBLOCK_ELEMENT_ID = be.ID AND p.IBLOCK_PROPERTY_ID = 42 WHERE be.IBLOCK_ID = 5 AND be.ACTIVE = 'Y' ORDER BY be.SORT LIMIT 20; ```Як ми оптимізуємо: покроковий процес
- EXPLAIN-аналіз — знаходимо повільні запити, визначаємо відсутні індекси.
- Додавання індексів — створюємо складені індекси для полів JOIN та фільтрації.
- Рефакторинг вибірки властивостей — розбиваємо запити з множинними властивостями, замінюємо LEFT JOIN на EXISTS.
- Переведення на D7 ORM — для критичних ділянок використовуємо D7 ORM з явним зазначенням відношень.
- Тестування — заміряємо час виконання до та після, фіксуємо результат.
D7 ORM: сучасний спосіб боротьби з JOIN
D7 ORM дозволяє контролювати, які таблиці включаються в JOIN через параметр runtime та явне налаштування relations. При роботі з HL-інфоблоками D7 генерує більш чисті запити без зайвих JOIN до b_iblock_element_property. Порівняйте: стандартний GetList на 10 властивостей — 10 JOIN, D7 ORM з HL-блоком — 0 JOIN на вибірці 10 000 елементів.
// Уникаємо JOIN до таблиці властивостей, працюємо напряму з HL-таблицею $result = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlBlock) ->getDataClass()::getList([ 'select' => ['ID', 'UF_PRODUCT_ID', 'UF_PRICE'], 'filter' => ['>=UF_PRICE' => 1000, '<=UF_PRICE' => 5000], 'limit' => 100, ]); Детальніше в D7 ORM документації.
Порівняння підходів до зберігання властивостей
| Сховище | JOIN до b_iblock_element_property | Продуктивність при 1М елементів | Індексація |
|---|---|---|---|
| Стандартні властивості | Так, множинні JOIN | Низька (2–5 с на запит) | Тільки по IBLOCK_ELEMENT_ID |
| UTS-таблиця | Так, один JOIN | Середня (0.5–2 с) | Можлива кастомна |
| HL-інфоблок | Ні | Висока (10–50 мс) | Гнучка індексація |
Процес роботи та терміни
| Задача | Термін | Ефект |
|---|---|---|
| EXPLAIN-аналіз JOIN-запитів, додавання індексів | 2–3 дні | Прискорення 5–20x на проблемних запитах |
| Рефакторинг вибірки властивостей (розбиття на підзапити) | 3–5 днів | Усунення декартового добутку |
| Переведення навантажених властивостей на HL-інфоблоки | 1–2 тижні | Усунення JOIN до b_iblock_element_property |
| Комплексна оптимізація каталогу | 2–3 тижні | Сторінка каталогу < 100 мс замість 2–5 с |
Вартість розраховується індивідуально. Середня вартість оптимізації одного інфоблоку становить 30 000 грн, а економія на серверних ресурсах — до 200 000 грн на рік. Один з наших клієнтів заощадив 150 000 грн на хостингу після оптимізації. Зв'яжіться з нами для безкоштовного аудиту вашого проєкту — оцінимо обсяг робіт та надамо попередні терміни.
Що входить у роботу
- Аудит поточних запитів та індексів (EXPLAIN, аналіз профілю сервера).
- Додавання та оптимізація індексів на ключові поля.
- Рефакторинг вибірки властивостей (розбиття множинних JOIN, заміна на підзапити).
- Переведення навантажених властивостей на HL-інфоблоки з міграцією даних.
- Документування змін та рекомендацій з підтримки.
- Навчання команди роботі з D7 ORM та налаштуванню кешування.
- Пост-проектна підтримка та супровід.
Чому варто довірити оптимізацію нам?
Понад 10 років ми розробляємо на Бітрікс, виконали 200+ проєктів з оптимізації продуктивності. Сертифікований партнер 1С-Бітрікс, гарантуємо прозорий процес і вимірні результати. Використовуємо найкращі практики, описані в документації.
JOIN-запити в Бітрікс — наслідок архітектурного рішення зберігати всі властивості в універсальній таблиці. При невеликих обсягах це працює. При зростанні даних потрібно або додавати індекси, або змінювати схему зберігання на HL-інфоблоки або власні таблиці. Ми допоможемо обрати оптимальний шлях. Замовте консультацію — ми проаналізуємо ваш проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами для безкоштовного аудиту.