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

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

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

Какие проблемы базы мы находим

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

Главные находки, которые попадают в отчёт по аудиту:

• запросы без индексов, идущие полным перебором таблицы вместо точечного поиска;
• неэффективные и неиспользуемые индексы, которые не подходят под реальные условия выборки;
• тяжёлые выборки инфоблоков: фильтрация по свойствам, сортировка и выборка лишних полей;
• проблема N+1, когда вместо одного запроса в цикле выполняются десятки и сотни;
• сортировки и группировки, которые выполняются на диске из-за нехватки буферов;
• блокировки и взаимные ожидания запросов, дающие зависания под нагрузкой;
• неоптимальные настройки InnoDB и буферного пула, не соответствующие объёму базы.

Чем slow query log и EXPLAIN полезнее интуиции

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

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

Что вы получаете на выходе

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

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

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

Почему именно база чаще всего виновата в тормозах

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

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

Что показывает slow query log и почему ему стоит доверять

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

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

Как EXPLAIN раскрывает, почему запрос медленный

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

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

Тяжёлые инфоблоки и проблема N+1

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

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

Блокировки, сортировки на диске и настройки InnoDB

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

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

Почему апгрейд железа не заменяет аудит

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

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

Что вы получаете и как это внедрять

Итог аудита — письменный отчёт со списком запросов от худшего к лучшему. По каждому запросу в нём текст запроса, его план выполнения, причина медленной работы, конкретная рекомендация, ожидаемый эффект и сложность внедрения. Это не абстрактные советы, а готовый план действий, по которому может работать ваша команда. Многие клиенты внедряют рекомендации сами — отчёт написан достаточно подробно для этого. Если же команда загружена или правки требуют глубокой экспертизы, мы внедряем их сами: добавляем индексы, переписываем выборки, убираем N+1, настраиваем InnoDB и делаем контрольный замер скорости до и после.

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

Как растёт нагрузка по мере развития проекта

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

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

Когда стоит заказывать аудит запросов

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

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