Анализ slow query log для 1С-Битрикс
Slow query log — журнал MySQL/MariaDB, в который сервер записывает запросы, выполнявшиеся дольше заданного порога. Это первый инструмент диагностики, когда сайт Битрикс работает медленно, а конкретные виновники неизвестны.
Включение и настройка
В my.cnf (или my.ini на Windows):
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1
min_examined_row_limit = 100
long_query_time = 0.5 — запросы дольше 500 мс. Для активной диагностики ставьте 0.1 или даже 0. log_queries_not_using_indexes = 1 — ловит запросы без индексов независимо от времени. min_examined_row_limit = 100 — не логировать быстрые запросы по маленьким таблицам.
Без перезапуска MySQL можно включить динамически:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = 1;
Анализ через mysqldumpslow и pt-query-digest
Сырой лог читать неудобно. Используйте утилиты агрегации:
mysqldumpslow — встроен в MySQL:
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
-s t — сортировка по суммарному времени, -t 10 — топ 10 запросов. Показывает шаблон запроса и суммарное/среднее время.
pt-query-digest (Percona Toolkit) — значительно информативнее: показывает процентиль времени выполнения, количество уникальных запросов, нагрузку на сервер.
Что ищем в логе Битрикс
Типичные паттерны медленных запросов в Битрикс:
-
SELECT ... FROM b_iblock_element WHERE IBLOCK_ID=Nбез индекса или сORDER BY SORTбез составного индекса -
SELECT ... FROM b_iblock_element_property WHERE VALUE LIKE '%текст%'—LIKEс ведущим%не использует индекс -
SELECT COUNT(*) FROM b_sale_order WHERE ...при нескольких миллионах заказов - Запросы к
b_search_contentбезFULLTEXT-индекса при полнотекстовом поиске - Пересоздание фасетного индекса (
b_iblock_find_*) при каждом изменении элемента
После нахождения конкретного запроса следующий шаг — EXPLAIN, который покажет, какой план выполнения выбрал оптимизатор и где добавить индекс.







