Очень часто «сайт тормозит» на Bitrix = база задыхается. Не потому что MySQL плохой, а потому что к нему обращаются как попало: тяжёлые фильтры, отсутствие индексов, лишние запросы.

Ниже — мой короткий рабочий чек-лист.

Как понять, что проблема именно в БД

Симптомы: • TTFB страницы прыгает, статика грузится быстро. • В htop/top mysqld висит в топе по CPU. • В SHOW PROCESSLIST куча долгих запросов в статусе Sending data / Locked. • При пике сайт отвечает рывками: то 200 мс, то 10 секунд.

Минимальные команды:

htop mysql -e "SHOW PROCESSLIST\G" | head -n 50

С чего начинаю: включаю slow query log

Без slow query log работа превращается в гадание.

В my.cnf:

slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1

Даю сайту поработать и смотрю:

mysqldumpslow -s t /var/log/mysql/slow.log | head

Именно оттуда обычно вылезают самые убийственные запросы по b_iblock_element, свойствам, заказам и HL-блокам.

Типичные убийцы производительности

1. Фильтр без индексов

SELECT * FROM b_iblock_element WHERE IBLOCK_ID = 10 AND ACTIVE = 'Y' ORDER BY SORT, ID DESC;

На большом инфоблоке без индекса по IBLOCK_ID и ACTIVE таблица просто перелопачивается.

Решение:

ALTER TABLE b_iblock_element ADD INDEX ix_iblock_active (IBLOCK_ID, ACTIVE);

2. Сортировка по полю без индекса

Сортировка по свойству/UF-полю без индекса в каталоге с тысячами товаров легко кладёт базу.

Что делаю: • выношу критичные поля в отдельную колонку/HL-блок; • ставлю индекс ровно под сортировку и фильтр.

3. LIKE ‘%строка%’ и монструозные фильтры

WHERE NAME LIKE '%iphone%' по большой таблице — почти гарантированный тормоз.

Варианты: • FULLTEXT-поиск там, где это уместно; • вынос поиска в отдельный движок; • честный разговор с бизнесом: все ли чекбоксы в фильтре реально нужны.

Что правлю на уровне Bitrix-кода • В GetList всегда задаю конкретный список полей, а не ['']. • Настраиваю нормальную пагинацию вместо «вытащить всё и посчитать в PHP». • Убираю N запросов в цикле, заменяя одним запросом по массиву ID. • Часто-используемые данные переношу в HL-блоки с индексами по UF_.

Чек-лист, когда база «задыхается» • Включён slow query log, есть топ медленных запросов. • Из логов понятно, какие таблицы страдают чаще всего. • По основным фильтрам и сортировкам сделаны составные индексы. • Убраны запросы с беспощадным LIKE '%строка%' и лишними OR. • В компонентах: • ограничено количество записей / настроена навигация; • не тянутся «все поля и все свойства».

Частые ошибки • Индексы ставят «на всё подряд», а не под реальные запросы. • SELECT тянет больше данных, чем реально нужно в шаблоне. • Фильтр меняли десять раз, а схему БД и индексы — ни разу. • Надеются, что MySQL сам «оптимизирует», а slow query log так и не включили.

Итог

В 90% случаев база в Bitrix «ложится» не из-за того, что «проект вырос», а из-за пары-тройки неудачных запросов и отсутствующих индексов. Найти эти запросы через slow query log, аккуратно добавить индексы и чуть дисциплинировать код — обычно хватает, чтобы сайт «поехал» без смены сервера и паники.