Оптимізація SQL-запитів 1С-Бітрікс

Оптимізація SQL-запитів 1С-Бітрікс

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

Як знайти проблемні запити

Перший крок — включити 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;
}

Трекер покаже всі запити за запит, їх час та стек викликів. Шукайте:

• запити довше 50 мс — вони гальмують сторінку помітно
• дублі — один і той же запит 10–50 разів на сторінку
• запити без WHERE по великим таблицям (b_iblock_element, b_sale_order_props)

Другий джерело — 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, індекса немає.

Бітрикс створює індекси при установці, але не при додаванні користувацьких полів через b_uts_iblock_N_single (UTS-таблиці для користувацьких типів). Індекси за цими таблицями потрібно додавати вручну.

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

CIBlockElement::GetList(
    ['SORT' => 'ASC'],
    ['IBLOCK_ID' => 5, 'ACTIVE' => 'Y'],
    false,
    ['nPageSize' => 20],
    ['ID', 'NAME', 'PREVIEW_PICTURE']  // тільки потрібні поля
);

Без $select запит включає LEFT JOIN b_iblock_element_iprop та інші таблиці, які не потрібні.

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

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

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

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

Індекс додається через 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): строкові поля індексуються за префіксом. Для числових значень, які зберігаються як VARCHAR, розгляньте віртуальний стовпець з приведенням типу.

Оптимізація через 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 — вбудоване кеширування на рівні запиту. Інвалідація — через тегований кеш при зміні елемента інфоблока.

Кеш як заміна зайвим запитам

Якщо дані змінюються раз на годину — немає смислу ходити в БД на кожний запит. Використовуйте \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);
}

При зміні будь-якого елемента інфоблока тег iblock_id_N інвалідується автоматично, та наступний запит йде в БД.

Тривалість робіт

Оптимізація SQL — не разова дія. Після змін потрібен регулярний моніторинг: slow query log раз на тиждень, трекер при релізах нових компонентів. Проблеми накопичуються по мірі зростання каталогу та обсягу даних.