Оптимизация SQL-запросов через EXPLAIN-анализ 1С-Битрикс
EXPLAIN — команда MySQL, которая показывает план выполнения запроса: какие таблицы сканируются, используются ли индексы, сколько строк обрабатывается. Это основной инструмент после обнаружения медленного запроса в slow query log.
Как читать EXPLAIN
EXPLAIN SELECT * FROM b_iblock_element
WHERE IBLOCK_ID = 5 AND ACTIVE = 'Y'
ORDER BY SORT;
Ключевые столбцы вывода:
| Столбец | На что смотреть |
|---|---|
type |
ALL = full scan (плохо), ref/range/const = использует индекс |
key |
Какой индекс выбрал оптимизатор, NULL = индекса нет |
rows |
Оценка числа строк для просмотра. 100 000+ при простой выборке — проблема |
Extra |
Using filesort = сортировка в памяти/на диске. Using temporary = временная таблица |
EXPLAIN ANALYZE (MySQL 8.0+, MariaDB 10.9+) выполняет запрос и показывает реальное время:
EXPLAIN ANALYZE SELECT ...;
Характерные проблемы Битрикс
Using filesort на b_iblock_element. Запрос сортирует по SORT, но индекс не покрывает комбинацию (IBLOCK_ID, ACTIVE, SORT). Решение: составной индекс:
ALTER TABLE b_iblock_element
ADD INDEX ix_iblock_active_sort (IBLOCK_ID, ACTIVE, SORT);
rows = 500 000 на запрос к b_iblock_element_property. Фильтрация по значению свойства без индекса по (IBLOCK_PROPERTY_ID, VALUE). Для VARCHAR-поля VALUE — индекс по префиксу VALUE(64).
Using temporary при GROUP BY. Встречается в запросах фасетного фильтра. Фасет Битрикса строит оптимизированные таблицы b_iblock_find_* — если они не пересозданы после добавления свойств, запросы идут в обход.
Порядок работы
- Получить медленный запрос из slow query log или SQL-трекера Битрикс
- Запустить
EXPLAIN— найтиtype=ALLилиrows> 10 000 при точечной выборке - Определить отсутствующий индекс или неэффективный JOIN
- Добавить индекс, повторить
EXPLAIN— убедиться, чтоtypeизменился - Проверить реальное время на боевых данных
После добавления индекса MySQL не всегда его выберет — если статистика таблицы устарела, запустите ANALYZE TABLE b_iblock_element для пересчёта.