Анализ медленных запросов на 1С-Битрикс: находим, что тормозит базу

Анализ медленных запросов — это диагностика базы данных и хитов сайта, которая отвечает на один практический вопрос: какие именно SQL-запросы и какие части кода съедают время отклика страниц. На 1С-Битрикс эта задача стоит особенно остро. Платформа генерирует много запросов на каждый хит, активно использует инфоблоки, highload-блоки, агенты и кэш, поэтому медленный отклик редко вызван чем-то одним. Чаще это сумма множества мелких неэффективностей: запрос без индекса, выборка лишних полей, тяжёлый фильтр по свойству инфоблока, агент, который раз в минуту перебирает всю таблицу. Без измерений всё это сливается в общее ощущение «сайт тормозит», и оптимизация превращается в угадывание.

Наша услуга снимает угадывание. Мы инструментально измеряем, где теряются миллисекунды, и выдаём ранжированный список реальных виновников — от самого дорогого запроса к самым дешёвым. Это не абстрактный аудит «всё плохо, переделывайте», а конкретный отчёт: вот эти двадцать запросов дают восемьдесят процентов задержки, вот почему они медленные, вот что с каждым из них делать. Дальше вы решаете, исправлять самим или с нашей помощью — приоритеты уже расставлены по соотношению эффекта и трудозатрат.

Чем анализ запросов отличается от общего ускорения

Общая оптимизация Битрикса работает с гипотезами: включить кэш, поднять версию PHP, настроить сервер. Это полезно, но бьёт по площадям. Анализ медленных запросов идёт от данных: сначала измеряем, потом делаем выводы. Мы не предполагаем, что тормозит каталог, — мы видим в логе, что запрос выборки товаров по свойству выполняется две секунды и вызывается на каждой странице раздела. Такой подход экономит бюджет: вы не оптимизируете то, что и так быстро, и не платите за работу, которая не сдвинет метрики.

Главные инструменты, которыми мы пользуемся при анализе:

• slow query log MySQL и MariaDB — журнал запросов, превысивших порог времени или прошедших без индекса;
• performance_schema и sys-схема — статистика по самым частым и самым дорогим запросам в сумме;
• встроенный профилировщик Битрикс и панель отладки — раскладка времени хита по компонентам и SQL;
• трассировка отдельных медленных страниц с замером каждого запроса и его плана выполнения;
• EXPLAIN и анализ планов — почему оптимизатор выбрал перебор таблицы вместо индекса;
• разбор агентов, крон-задач и отложенных операций, которые грузят базу в фоне.

Кому нужен анализ медленных запросов

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

Отдельный частый случай — когда сервер регулярно упирается в процессор или диск, хостер просит снизить нагрузку, а где именно она возникает, никто не знает. Анализ запросов показывает источник: чаще всего это несколько прожорливых выборок и пара фоновых агентов, а вовсе не «слабый сервер». Заменить тариф проще, но дороже и часто бесполезно, если проблема в одном запросе без индекса.

Что вы получаете в результате

Итог анализа — структурированный отчёт о топ-медленных запросах. По каждому запросу мы показываем текст, частоту вызова, среднее и суммарное время, план выполнения и причину медлительности: отсутствие индекса, выборка лишних колонок, неоптимальный фильтр, проблема на стороне компонента или агента. К каждому пункту прилагается рекомендация: что добавить, что переписать, что закэшировать, что вынести в фон. Рекомендации отсортированы по эффекту, чтобы вы начали с того, что даст максимум ускорения при минимуме работы.

Помимо списка запросов отчёт содержит карту узких мест по разделам сайта, оценку влияния каждого на общее время отклика и план внедрения исправлений. Если нужно, мы сопровождаем внедрение и повторно замеряем результат, чтобы убедиться, что страницы реально ускорились, а нагрузка на базу упала. Так анализ превращается из разового документа в измеримый рост скорости, который видят и пользователи, и поисковые системы.

Почему важно мерить, а не угадывать

Самая частая ошибка при борьбе с тормозами — оптимизировать по интуиции. Кажется, что виноват каталог, и команда тратит недели на его переписывание, а реальная задержка всё это время жила в фоновом агенте, который раз в минуту перебирал таблицу заказов. Без измерений такие ошибки неизбежны: глаз человека не видит, какой из сотен запросов на странице съедает время, а догадки строятся на старых представлениях о проекте, которые давно устарели вместе с ростом данных. Инструментальный анализ убирает эту неопределённость и направляет усилия туда, где они дадут максимальную отдачу.

Измеримость даёт ещё одно важное преимущество — она делает разговор о скорости деловым. Вместо размытого «сайт медленный» появляются конкретные цифры: эта страница отвечает за два с лишним секунды, восемьдесят процентов из которых приходится на три запроса, исправление каждого описано и оценено по трудозатратам. С такими данными решение об оптимизации принимается так же спокойно, как любое другое деловое решение, где известны затраты и ожидаемый результат. Именно поэтому анализ медленных запросов — это не техническая прихоть, а инструмент управления скоростью и расходами на инфраструктуру.

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

Почему Битрикс тормозит именно на базе

Битрикс — платформа, которая на каждый хит обращается к базе данных десятки, а на сложных страницах и сотни раз. Каталог собирает товары, свойства, цены и остатки. Личный кабинет тянет заказы, документы и историю. Фильтры по характеристикам строят выборки по таблицам свойств инфоблоков, которые на больших объёмах превращаются в перебор миллионов строк. Добавьте сюда агенты, которые в фоне пересчитывают данные, и крон-задачи, и вы получаете базу, по которой постоянно идёт интенсивный поток запросов. Стоит одному из них быть написанным без учёта индексов — и он начинает тормозить всю страницу, а под нагрузкой утягивает за собой и соседние.

Коварство в том, что на маленьких объёмах данных такой запрос работает мгновенно и проблему не видно. Магазин запускается с тысячей товаров — всё летает. Через два года в каталоге пятьдесят тысяч позиций, а запрос остался прежним, и теперь он выполняется не миллисекунды, а секунды. Сайт «вдруг» начал тормозить, хотя код не менялся. Изменился объём, под который этот код никогда не был рассчитан. Найти такое глазами в тысячах строк невозможно — нужен инструмент, который покажет, какой именно запрос стал узким местом.

Как мы находим настоящих виновников

Мы не верим ощущениям и не оптимизируем по списку «лучших практик». Мы измеряем. Первым делом включаем slow query log — журнал, в который база складывает все запросы, превысившие порог времени или прошедшие без индекса. Параллельно собираем статистику через performance_schema и sys-схему: они показывают не только самые медленные по одному запросу, но и самые дорогие в сумме — те, что выполняются по сто миллисекунд, но тысячу раз за минуту и в итоге дают основную нагрузку. Дальше подключаем встроенный профилировщик Битрикс и панель производительности, которые раскладывают время каждого хита по компонентам, шаблонам и SQL.

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

Почему апгрейд сервера часто не помогает

Представьте запрос, который перебирает миллион строк, потому что для него нет индекса. На более мощном сервере он будет перебирать тот же миллион строк — просто чуть быстрее за счёт более шустрого процессора и диска. Вы заплатили вдвое больше, а получили выигрыш в десятки процентов, и то временно: вырастут данные — и преимущество съестся. Тот же самый запрос с правильным индексом начнёт трогать не миллион строк, а десяток, и ускорится не на проценты, а в сотни раз. Причём на прежнем сервере. Вот почему анализ запросов почти всегда выгоднее апгрейда: он бьёт в корень проблемы, а не в её последствия.

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

Когда апгрейд всё-таки нужен

Мы не утверждаем, что железо не важно. Бывают проекты, которые честно переросли свой сервер: запросы уже оптимальны, кэш настроен, код вычищен, а трафик и объём данных продолжают расти. В таком случае апгрейд или переход на отдельный сервер базы данных оправдан, и мы прямо об этом говорим. Разница в том, что после анализа вы апгрейдите не вслепую, а зная, что выжали из текущей инфраструктуры всё. Тогда каждый рубль, вложенный в железо, работает на полную, а не компенсирует неисправленный запрос. Если выяснится, что узкое место именно в инфраструктуре, поможет направление по базе данных и запросам, где мы смотрим настройки СУБД и сервера в комплексе.

Чем анализ отличается от обычного аудита

Многие аудиты заканчиваются документом из общих рекомендаций: включите кэш, обновите PHP, почистите модули. Это полезные советы, но они не отвечают на вопрос, что именно тормозит ваш конкретный сайт. Наш анализ медленных запросов всегда конкретен. В отчёте не написано «база работает медленно» — написано «вот этот запрос выборки товаров по свойству цвет выполняется 2,1 секунды, вызывается на каждой странице раздела, причина — отсутствие индекса по таблице свойств, решение — добавить составной индекс, ожидаемое ускорение в сорок раз». С таким отчётом понятно, что делать, и видно, сколько это даст. Если нужен ещё более глубокий взгляд на сами запросы и план их переписывания, его даёт аудит медленных SQL-запросов Битрикс.

Что происходит после отчёта

Отчёт — это карта, но ехать по ней можно по-разному. Часть клиентов берёт его и внедряет исправления силами своих разработчиков: приоритеты расставлены, причины описаны, остаётся применить. Часть просит нас довести работу до конца — добавить индексы, переписать тяжёлые запросы, оптимизировать компоненты, вынести фоновые задачи из пиковых часов. В обоих случаях мы рекомендуем после внедрения сделать контрольный замер: повторно прогнать профилировщик и сравнить время хитов и нагрузку на базу с исходными. Без замера легко обмануться ощущением «вроде стало быстрее» — а цифры показывают честную картину и подтверждают, что деньги потрачены не зря.

Отдельно стоит сказать про повторяемость. База живёт: добавляются товары, растёт число заказов, появляются новые разделы и фильтры. Запрос, который сегодня быстрый, через полгода может стать узким местом на возросшем объёме. Поэтому для активно растущих проектов мы предлагаем настроить постоянный мониторинг медленных запросов, чтобы новые проблемы всплывали в логе сразу, а не тогда, когда сайт уже лёг. Это превращает разовую диагностику в регулярную гигиену базы, которая стоит копейки по сравнению с простоем в час пик.

Как анализ влияет на бизнес

Скорость — это не абстрактная техническая метрика, а деньги и репутация. Медленный каталог роняет конверсию: посетитель не ждёт, пока подгрузится фильтр, и уходит к конкуренту. Медленные страницы хуже ранжируются в поиске, потому что поисковые системы давно учитывают время отклика и стабильность. Медленный личный кабинет раздражает менеджеров и клиентов и съедает рабочее время. А база, которая ложится в часы пик, может обрушить весь сайт именно в тот момент, когда трафик и продажи на максимуме. Анализ медленных запросов адресно бьёт по всем этим точкам, возвращая скорость там, где она напрямую конвертируется в выручку.

Важно, что эффект измерим и предсказуем. Мы не обещаем абстрактное «станет лучше» — мы показываем в отчёте, на сколько ускорится каждая ключевая страница после конкретного исправления, и подтверждаем это замером. Вы видите вложение и отдачу в одних и тех же единицах: было столько-то секунд и столько-то нагрузки, стало столько-то. Это делает решение об оптимизации таким же понятным, как любое другое деловое решение, где есть затраты и результат.

Типичные находки на проектах Битрикс

За годы работы с нагруженными проектами мы видим, что виновники тормозов повторяются от сайта к сайту. На первом месте — выборки товаров с фильтрацией по свойствам инфоблоков без подходящих индексов: они растут вместе с каталогом и однажды начинают занимать секунды. На втором — компоненты, которые делают запросы в цикле: вместо одной выборки на сто строк уходит сто отдельных запросов, и страница тонет в накладных расходах на соединения. Дальше идут тяжёлые агенты и крон-задачи, которые в фоне перебирают большие таблицы и создают пики нагрузки в строго определённые минуты. Замыкают список выборки с лишними колонками и сортировки по неиндексированным полям, которые заставляют базу строить временные таблицы на диске.

Знание этих паттернов ускоряет диагностику: мы понимаем, где искать в первую очередь, и не тратим время клиента на проверку маловероятных гипотез. Но мы никогда не подменяем измерения опытом — паттерны лишь подсказывают, куда смотреть, а решение принимается по фактическим данным из логов и профилей. Так сочетаются скорость поиска и точность выводов: вы получаете отчёт быстро, но без домыслов, основанный на том, что реально происходит в вашей базе под вашим трафиком.

Как анализ встраивается в развитие проекта

Анализ медленных запросов — не финальная точка, а часть жизненного цикла сайта. Лучше всего он работает, когда становится регулярной практикой: после крупных релизов, при заметном росте каталога или трафика, перед сезонными пиками продаж. Новый функционал почти всегда приносит новые запросы, и какие-то из них со временем станут узкими местами. Если ловить их сразу в логе, исправление обходится в час работы, а не в авральное тушение пожара, когда сайт уже лёг в день распродажи. Поэтому для растущих проектов мы выстраиваем процесс так, чтобы медленные запросы всплывали на ранней стадии и попадали к разработчикам до того, как их заметят пользователи.

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

С чего начать

Начать проще всего с разговора. Расскажите, какие страницы тормозят, в какие моменты и под какой нагрузкой, есть ли жалобы от хостера и доступ к серверу. Мы подскажем, какой формат анализа подойдёт — экспресс-разбор самых тяжёлых запросов или полную диагностику базы, профилей и кода. На коротком брифе мы прикинем объём работы и пришлём смету в течение рабочего дня. А дальше — собираем данные, находим настоящих виновников тормозов и отдаём отчёт, по которому ваш сайт станет ощутимо быстрее. Без угадывания, без лишних трат на железо и с измеримым результатом, который видят и пользователи, и поисковые системы.