Повний аудит SQL-запитів для 1С-Бітрікс: індекси, кешування та D7 ORM

Як прискорити 1С-Бітрікс: повний аудит SQL-запитів, індексів та кешування

На типовому навантаженому сайті Бітрікс генерує від 200 до 1000 SQL-запитів на сторінку. Більшість із них — повторювані, надлишкові або з SELECT *. Перш ніж купувати дорожчий сервер, варто розібратися, які саме запити гальмують і чому. За 10 років роботи з Бітрікс ми не раз бачили проєкти, де один неправильний індекс або відсутність кешу з'їдали 70% ресурсів БД. Середня економія після аудиту — значна та залежить від конкретних умов.

Оптимізація SQL-запитів — не разова дія, а регулярний процес. Наші клієнти економлять до 50% навантаження сервера та прискорюють генерацію сторінок у 2-5 разів. Окупається така оптимізація за 2-3 місяці. Давайте подивимося, як виявити вузькі місця та усунути їх.

Приклад із практики: інтернет-магазин із каталогом 50 000 товарів. Головна сторінка формувалася 12 секунд. Після профілювання виявили 15 запитів до b_iblock_element_property без індексу — у два рази швидше. Додали композитний індекс — сторінка почала завантажуватися за 0.4 с. Економія на сервері — значна.

Як виявити повільні SQL-запити: покрокова інструкція

1. Увімкніть SQL-трекер Бітрікса на панелі продуктивності (/bitrix/admin/perfmon_panel.php) або додайте програмний запис:

\Bitrix\Main\Diag\SqlTracker::getInstance()->start();
// ... ваш код ...
$tracker = \Bitrix\Main\Diag\SqlTracker::getInstance();
$tracker->stop();
foreach ($tracker->getQueries() as $query) {
    echo $query->getSql() . ' — ' . $query->getTime() . 'ms' . PHP_EOL;
}

2. Проаналізуйте трекер: шукайте запити довші за 50 мс, дублі (той самий запит повторюється 10—50 разів на сторінку), запити без WHERE по великих таблицях.

3. Додатково увімкніть slow_query_log у MySQL/MariaDB (long_query_time = 0.5 у my.cnf) — він дає реальну картину під навантаженням у продакшені.

Чому індекси критичні для Бітрікса?

b_iblock_element може містити від 10 000 до 1 000 000 рядків. Запит SELECT * FROM b_iblock_element WHERE IBLOCK_ID = 5 AND ACTIVE = 'Y' ORDER BY SORT без індексу по (IBLOCK_ID, ACTIVE, SORT) виконує full table scan. Перевірте через EXPLAIN SELECT ... — якщо в type побачите ALL, індексу немає. Селективність індексу має бути високою — уникайте стовпців із низькою кардинальністю.

Бітрікс створює індекси при встановленні, але не для користувацьких полів (UTS-таблиці b_uts_iblock_N_single). Індекси по цих таблицях потрібно додавати вручну. За нашим досвідом, правильні індекси прискорюють конкретні запити в 2–10 разів. Детальніше про індекси БД — у статті Wikipedia: «Індекс (бази даних)».

Надлишкова вибірка полів

CIBlockElement::GetList() за замовчуванням робить LEFT JOIN з b_iblock_element_iprop і повертає десятки полів, включаючи DETAIL_TEXT вагою в мегабайти. Якщо на сторінці потрібні лише ID, NAME та PREVIEW_PICTURE — задавайте $select явно:

CIBlockElement::GetList(
    ['SORT' => 'ASC'],
    ['IBLOCK_ID' => 5, 'ACTIVE' => 'Y'],
    false,
    ['nPageSize' => 20],
    ['ID', 'NAME', 'PREVIEW_PICTURE']
);

Це знижує навантаження на 20–40%.

N+1 проблема та способи її усунути

Класична ситуація: завантажили 20 елементів, потім у циклі для кожного окремим запитом завантажуєте властивості. Підсумок — 21 запит замість 1–2. У старому API вирішується через $arSelectFields, у D7 — через fetchCollection() із fill(). Після оптимізації кількість запитів знижується в 3–5 разів.

Повторні запити одних і тих самих даних

Налаштування сайту, групи користувачів, розділи інфоблоків — запитуються на кожній сторінці повторно. Стандартний кеш Бітрікса (BXCache) повинен це закривати, але якщо кеш вимкнено або тегований кеш скидається часто — запити йдуть у БД. Рекомендації Бітрікс — використовувати тегований кеш.

Що дає кешування на рівні запитів?

Якщо дані змінюються раз на годину, немає сенсу ходити в БД на кожен запит. Використовуйте \Bitrix\Main\Data\Cache із тегованим кешем:

$cache = \Bitrix\Main\Data\Cache::createInstance();
$cacheId = 'catalog_top_' . $iblockId;
$cachePath = '/catalog/top/';

if ($cache->initCache(3600, $cacheId, $cachePath)) {
    $data = $cache->getVars();
} elseif ($cache->startDataCache()) {
    $tagCache = new \Bitrix\Main\Data\TaggedCache();
    $tagCache->startTagCache($cachePath);

    $data = /* ваш запит */;

    $tagCache->registerTag('iblock_id_' . $iblockId);
    $tagCache->endTagCache();
    $cache->endDataCache($data);
}

При зміні будь-якого елемента інфоблоку тег автоматично інвалідується. Тегований кеш швидший за звичайний у 3–5 разів за часом інвалідації.

Оптимізація через D7 ORM

D7 ORM дає можливість точково керувати запитом. Порівняйте:

// Погано: завантажує всі поля, всі властивості
$result = \Bitrix\Iblock\ElementTable::getList([
    'filter' => ['IBLOCK_ID' => 5, 'ACTIVE' => 'Y'],
]);

// Краще: тільки потрібні поля, явний ліміт, кеш
$result = \Bitrix\Iblock\ElementTable::getList([
    'select' => ['ID', 'NAME', 'PREVIEW_PICTURE_ID'],
    'filter' => ['IBLOCK_ID' => 5, 'ACTIVE' => 'Y'],
    'order'  => ['SORT' => 'ASC'],
    'limit'  => 20,
    'offset' => 0,
    'cache'  => ['ttl' => 3600],
]);

Параметр cache у запиті ORM — вбудоване кешування. D7 ORM швидший за старий API у 2–3 рази на вибірках.

Робота з індексами

Додавання відсутніх індексів — найшвидше рішення з найбільшим ефектом. Ось таблиця найбільш корисних індексів:

Індекс додається через SQL або Бітрікс ORM:

$connection = \Bitrix\Main\Application::getConnection();
$connection->queryExecute(
    "ALTER TABLE b_iblock_element_property ADD INDEX ix_prop_val (IBLOCK_PROPERTY_ID, VALUE(64))"
);

Обережно з VALUE(64): строкові поля індексуються за префіксом. Для числових значень розгляньте віртуальний стовпець. Докладніше — у статті Wikipedia про індекси БД.

Типові проблеми на проєктах: В одній компанії 6 місяців не могли зрозуміти, чому кошик гальмує на 10 секунд. Виявилося, запит до b_sale_basket без індексу по FUSER_ID. Додали індекс — час упав до 0.1 с. Інший проєкт: на сторінці списку замовлень (admin) виконувалося 10 000 запитів через N+1 у кастомному компоненті. Після рефакторингу — 50 запитів.

Строки робіт

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

• Аудит поточних SQL-запитів та виявлення вузьких місць.
• Розробка та реалізація індексів, оптимізація вибірок.
• Впровадження кешування та перехід на D7 ORM.
• Документація змін та рекомендації щодо моніторингу.
• Навчання розробників вашої команди.
• Гарантія 3 місяці на коректність оптимізації.

10 років досвіду, сертифікати Бітрікс та 200+ успішних проєктів гарантують якість. Кожен день високого навантаження коштує бізнесу значних коштів — оптимізація окупається за кілька місяців.

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

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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.