Оптимізація JOIN-запитів у 1С-Бітрікс: індекси, D7 ORM та HL-блоки

Уявіть: сторінка каталогу з фільтром завантажується 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.

Як ми оптимізуємо: покроковий процес

1. EXPLAIN-аналіз — знаходимо повільні запити, визначаємо відсутні індекси.
2. Додавання індексів — створюємо складені індекси для полів JOIN та фільтрації.
3. Рефакторинг вибірки властивостей — розбиваємо запити з множинними властивостями, замінюємо LEFT JOIN на EXISTS.
4. Переведення на D7 ORM — для критичних ділянок використовуємо D7 ORM з явним зазначенням відношень.
5. Тестування — заміряємо час виконання до та після, фіксуємо результат.

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 документації.

Порівняння підходів до зберігання властивостей

Процес роботи та терміни

Вартість розраховується індивідуально. Середня вартість оптимізації одного інфоблоку становить 30 000 грн, а економія на серверних ресурсах — до 200 000 грн на рік. Один з наших клієнтів заощадив 150 000 грн на хостингу після оптимізації. Зв'яжіться з нами для безкоштовного аудиту вашого проєкту — оцінимо обсяг робіт та надамо попередні терміни.

Що входить у роботу

• Аудит поточних запитів та індексів (EXPLAIN, аналіз профілю сервера).
• Додавання та оптимізація індексів на ключові поля.
• Рефакторинг вибірки властивостей (розбиття множинних JOIN, заміна на підзапити).
• Переведення навантажених властивостей на HL-інфоблоки з міграцією даних.
• Документування змін та рекомендацій з підтримки.
• Навчання команди роботі з D7 ORM та налаштуванню кешування.
• Пост-проектна підтримка та супровід.

Чому варто довірити оптимізацію нам?

Понад 10 років ми розробляємо на Бітрікс, виконали 200+ проєктів з оптимізації продуктивності. Сертифікований партнер 1С-Бітрікс, гарантуємо прозорий процес і вимірні результати. Використовуємо найкращі практики, описані в документації.

JOIN-запити в Бітрікс — наслідок архітектурного рішення зберігати всі властивості в універсальній таблиці. При невеликих обсягах це працює. При зростанні даних потрібно або додавати індекси, або змінювати схему зберігання на HL-інфоблоки або власні таблиці. Ми допоможемо обрати оптимальний шлях. Замовте консультацію — ми проаналізуємо ваш проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами для безкоштовного аудиту.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Що входить у роботу?

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.