Инструментарий диагностики SQL рядом с Битрикс

Зачем администратору Битрикс знать инструменты MySQL

Ядро, модули и ваш кастом формируют SQL к одной и той же базе. Когда тормозит каталог, обмен или отчёт, без снимка плана и метрик вы гадаете. Ниже — практичный набор команд и схем, с которого обычно начинают разбор.

EXPLAIN и план запроса

EXPLAIN для подозрительного SELECT — первый шаг. В выводе смотрите тип доступа, оценку строк, используемый ключ и поле Extra:

Using index — запрос закрывается из индекса (часто удачный вариант для узких выборок).
Using where — фильтр после чтения; есть ли индекс под условие, видно по possible_keys и key.
Using temporary — промежуточная таблица для сортировки или группировки.
Using filesort — сортировка не укладывается в порядок индекса; «файл» в названии не обязан быть большим, но при нехватке памяти сортировка может уйти на диск.

В MySQL 8.0.18+ для измерения фактического времени по шагам плана удобен EXPLAIN ANALYZE — он выполняет запрос и показывает реальные числа, а не только оценки оптимизатора.

EXPLAIN SELECT e.ID, e.NAME
  FROM b_iblock_element e
 WHERE e.IBLOCK_ID = 5 AND e.ACTIVE = 'Y'
   AND e.ID IN (101, 205, 340);

EXPLAIN ANALYZE SELECT COUNT(*) FROM b_sale_order WHERE DATE_INSERT > '2025-01-01';

Общее состояние сервера: PROCESSLIST и SHOW

Быстрый «пульс» инстанса:

SHOW FULL PROCESSLIST — кто держит соединение и какой текст запроса (аккуратно с длинными строками и правами).
SHOW VARIABLES и узкий поиск, например SHOW VARIABLES LIKE 'innodb_%' или LIKE 'sql_%' — буферы, лимиты, режимы SQL.
SHOW TABLE STATUS в нужной базе и при необходимости с WHERE Engine='InnoDB' — ориентир по строкам и занятому месту на уровне таблицы (статистика приблизительная для InnoDB).
SHOW CREATE TABLE `b_iblock_element` — фактические типы и индексы без панели phpMyAdmin.

SHOW FULL PROCESSLIST;
SHOW VARIABLES LIKE 'slow_query%';
SHOW TABLE STATUS FROM your_bitrix_db WHERE Engine = 'InnoDB';

Information Schema

Сводки по метаданным удобно собирать запросами к INFORMATION_SCHEMA: таблицы, движок, грубая оценка строк, объём данных и индексов. Значение TABLE_ROWS для InnoDB — оценка; для точного COUNT(*) по большим таблицам считайте отдельно и не в пик нагрузки.

SELECT TABLE_NAME, TABLE_ROWS, ENGINE,
       ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 1) AS size_mb
  FROM INFORMATION_SCHEMA.TABLES
 WHERE TABLE_SCHEMA = 'your_bitrix_db'
 ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
 LIMIT 40;

Лог медленных запросов

На современных сборках ориентируйтесь на переменные вида slow_query_log, long_query_time, log_output, log_queries_not_using_indexes (имена в документации к вашей точной версии). Лог можно направить в файл или в таблицы mysql.slow_log — что удобнее для ротации и анализа на вашем хостинге. Порог секунд подбирайте под SLA витрины: для Битрикс часто начинают с единиц секунд и сужают после первых выборок.

-- примеры имён; перечень переменных на сервере: SHOW VARIABLES LIKE 'slow%';
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;
-- просмотр табличного лога
SELECT start_time, query_time, rows_sent, rows_examined, sql_text
  FROM mysql.slow_log
 WHERE db = 'your_bitrix_db'
 ORDER BY start_time DESC LIMIT 50;

Счётчики сессии

SHOW SESSION STATUS LIKE 'Handler%' и смежные префиксы помогают увидеть, сколько раз движок ходил в индекс/таблицу в рамках соединения. Перед серией экспериментов можно обнулить сессионную статистику командой FLUSH STATUS (не путать с глобальным состоянием). Для тяжёлого запроса из приложения иногда добавляют SQL_NO_CACHE в тестах на старых конфигурациях, чтобы не смешивать эффект кэшей клиента и сервера.

Профайлинг: legacy и MySQL 8

Классические SET profiling = 1 и SHOW PROFILE в новых версиях MySQL считают устаревшими или отключены; ориентируйтесь на EXPLAIN ANALYZE, отчёты performance_schema и внешние утилиты. Для глубокого разбора на бою включают сбор событий по согласованию с администратором — инструменты сами по себе лёгкие, но неправильный сбор может раздувать накладные расходы.

Percona Toolkit и разбор логов

Набор утилит Percona Toolkit (например, сводка дубликатов индексов, разбор slow-логов, визуализация планов) полезен, когда задача выходит за рамки пары запросов в консоли. На продакшене запускайте с копией лога или на staging, не блокируя основной инстанс длинными сканированиями.

Кратко

Снимите план (EXPLAIN / EXPLAIN ANALYZE), проверьте индекс и Extra, посмотрите PROCESSLIST и slow log, при необходимости оцените размеры таблиц через INFORMATION_SCHEMA — этого достаточно, чтобы отличить «плохой SQL» от «упёрлись в диск/параметры» в типичном проекте на 1С‑Битрикс.