Медленные запросы MySQL находят по журналу медленных запросов (slow query log): включают запись всего, что выполняется дольше порога в 1-2 секунды, собирают статистику несколько дней, затем разбирают лидеров командой EXPLAIN и чинят - индексами, переписыванием запроса или кэшированием результата. В Битрикс есть и свой инструмент: монитор производительности показывает все SQL-запросы страницы с временем выполнения прямо в админке. Ниже - весь путь от «сайт тормозит» до конкретного запроса и его лечения.

Правило 80/20. В типовом проекте основную нагрузку на базу создают 2-3 запроса: тяжёлый фильтр каталога, выборка меню по всему дереву разделов, пересчёт остатков. Не нужно чинить всё подряд - найдите лидеров, и база задышит.

Как медленные запросы MySQL проявляются на сайте

  • Долгое ожидание первого байта - страница «думает» 2-5 секунд до начала загрузки
  • Тормозит фильтр и поиск каталога - чем больше отмечено параметров, тем дольше ответ
  • Админка виснет на списках - разделы с товарами и заказами открываются десятки секунд
  • Сайт падает при трафике - запросы копятся в очередь, посетители получают 502 и 503
  • Скрипты обрываются по тайм-ауту - классика из нашей статьи про Maximum execution time exceeded

Как найти медленные запросы MySQL: пошагово

  1. Включите slow query logВ настройках MySQL задайте long_query_time = 1 и путь к журналу. Накладные расходы минимальны, включать на рабочем сайте безопасно.
  2. Соберите статистику 3-7 днейЖурнал должен захватить будни, выходные и часы пик. Сводку по лидерам удобно смотреть утилитами mysqldumpslow или pt-query-digest.
  3. Разберите лидеров через EXPLAINКоманда показывает план выполнения: если в колонке type стоит ALL, а в rows - сотни тысяч, MySQL перебирает таблицу целиком вместо работы по индексу.
  4. Сверьтесь с монитором БитриксНастройки - Производительность - вкладка для разработчиков: видно, какие запросы генерирует конкретная страница и сколько каждый длится.
  5. Зафиксируйте скорость до правокЗамерьте время ответа проблемных страниц. Без базовой точки вы не докажете эффект и не заметите регресс.

Чем лечат медленные запросы: индексы, код, кэш

Индексы - первое лекарство: поля, по которым фильтруют, сортируют и связывают таблицы, должны быть проиндексированы. Один правильный составной индекс ускоряет запрос в десятки раз.

Второе - переписывание. Типичная болезнь проектов на Битрикс - выборки в цикле: компонент получает список товаров, а затем для каждого делает отдельный запрос за ценами или картинками. Сто товаров - сто лишних запросов на страницу. Лечится одной общей выборкой с нужными полями.

Третье - кэширование: результат тяжёлого, но редко меняющегося запроса (меню, фильтры, блоки главной) складывается в кэш и пересчитывается раз в час, а не при каждом открытии страницы.

Важно. Не вешайте индексы на всё подряд: каждый индекс замедляет запись и раздувает базу. И не правьте настройки MySQL пачкой - по одному параметру, с бэкапом и замером. Перегнёте с лимитами - получите ошибки соединения, о которых мы писали в разборе MySQL server has gone away.

База тормозит, а времени разбираться нет?

Проведём аудит: включим журналы, найдём тяжёлые запросы, покажем отчёт «что тормозит и почему» и ускорим - индексами, правками кода и кэшированием.

Ускорить базу
Быстрая мера. Пока запросы не починены, включите кэширование тяжёлых компонентов и композитный кэш - нагрузка на базу упадёт сразу, и вы выиграете время на нормальную оптимизацию.

Сколько стоит оптимизация медленных запросов

Разбор и ускорение типовых тяжёлых запросов - от 100-200 BYN разово: аудит журналов, индексы, точечные правки компонентов. Глубокая оптимизация крупного каталога с переработкой выборок и кэшированием - от 300 до 800 BYN, срок 3-7 дней. На абонентской поддержке контроль базы идёт постоянно: журналы, метрики и реакция на деградацию входят в тариф.

Частые вопросы о медленных запросах

Почему запросы MySQL стали медленными, хотя код не меняли?
Выросли данные. На 1000 товаров полный перебор таблицы незаметен, на 50 000 - это уже секунды на каждый запрос. Запрос, написанный без индекса, стареет вместе с базой: чем больше строк, тем он медленнее.
Поможет ли просто взять сервер мощнее?
Отсрочит проблему. Запрос с полным перебором растёт вместе с данными и упрётся в любое железо. Правильный порядок: сначала индексы и код, потом ресурсы - иначе вы будете оплачивать сервер, который тратит мощность впустую.
Что такое EXPLAIN простыми словами?
Команда, которая показывает план: как MySQL собирается выполнять запрос - по какому индексу или полным перебором строк. Главные сигналы проблемы: type = ALL и большие числа в колонке rows.
Опасно ли включать slow query log на боевом сайте?
Нет: запись почти не нагружает сервер. Настройте ротацию журнала, чтобы файл не разросся, и отключите подробные режимы после сбора статистики.

Медленные запросы - самая благодарная оптимизация: пара индексов и переработанная выборка ощущаются посетителями сразу. Не хотите копаться в EXPLAIN сами - передайте базу нам: в рамках доработки сайтов найдём и ускорим узкие места. С 2013 года и 450+ проектов мы насмотрелись на все варианты тормозов. Диагностика бесплатная, смета - за 1 день.